building a package that can not be upgraded
valery_reznic at yahoo.com
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 bmsi.com>
>To: General discussion about the RPM package manager <rpm-list at lists.rpm.org>
>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
>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 lists.rpm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rpm-list