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
