RE: building a package that can not be upgraded

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jul 9, Hebenstreit, Michael transmitted in part:

I can think of some complex packages with very involved installation
procedures where upgrading might be a problem. Other than that, no, canʼt
think of anything else

One example of such packages are database applications, e.g. roundup and
moin (and our accounting programs).  Those can be updated for bug fixes
with no problem, but then they have schema changes that require
migrating the data before updating the program.  The migration typically
requires manual intervention.

It *seems* that this case is served by conditionally preventing upgrade,
i.e. the %pre checks the schema to make sure it is compatible.  However,
there are typically arbitrary and multiple data instances for such
a package - multiple roundup instances, multiple moin wikis, multiple
companies for accounting software.

There is no reliable way for %pre to find and check all instances.  The
best we've been able to come up with is to check the schema at startup,
and refuse to run until migrated.  This is not ideal.  This is a large
dark problem.

Probably, the best solution is for migration to be automated, and the
user/admin asked to confirm migration at startup (suggesting they backup
first, yada, yada).
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux