building a package that can not be upgraded

Valery Reznic 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.

Valery




>________________________________
> 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
>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 lists.rpm.org
>http://lists.rpm.org/mailman/listinfo/rpm-list
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20120717/afc33a28/attachment.html>


More information about the Rpm-list mailing list