building a package that can not be upgraded

Stuart D Gathman stuart at bmsi.com
Tue Jul 10 16:11:26 UTC 2012


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).


More information about the Rpm-list mailing list