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@xxxxxxxx>
To: General discussion about the RPM package manager <rpm-list@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
