building a package that can not be upgraded

Valery Reznic valery_reznic at
Tue Jul 17 13:52:56 UTC 2012

Interesting example, but still here upgrade should be disable if some condition is true (or false :)
Initial questions was how to disable it unconditionally and I wandered why one may want such a thing.


> From: Stuart D Gathman <stuart at>
>To: General discussion about the RPM package manager <rpm-list at> 
>Sent: Tuesday, July 10, 2012 7:11 PM
>Subject: RE: building a package that can not be upgraded
>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 at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Rpm-list mailing list