On Jan 22, 2009, at 5:43 PM, Les Mikesell wrote:
Personally, I think that database upgrades have almost nothing to do with instaling packages, but I'd rather add whatever is useful than discuss well known RPM deficiencies for another decade.
The reason the discussion is intertwined with packaging is that if you name the delivered files the same, the old and new can never co- exist as they should for the conversion and test period.
In fact, the old <-> new can/do coexist during upgrade; lib/fsm.c in RPM has had a form of apply/commit since forever that puts the new in place (the apply) but does not remove the old (renaming into old is the commit).
And there are provisions to rename the old into a subdirectory as part of committing the new; at least the necessary path name generation including a subdirectory has been there since forever in RPM. Adding the necessary logic to achieve whatever goal is desired installing files is just not that hard, the code is a state machine.
Personally (and as I pointed out), including old files in the new package is likelier to be reliable, and has the additional benefit that whatever conversions are needed can be done anytime, not just during a "window" during upgrade where old <-> new coexist. A conversion side-effect at the scale of a database conversion is hugely complicated to guarantee reliability during a "window". Are you volunteering to test?
I think the only way it can be done reasonably is to install the new code with different names and/or paths and scripts that can be run later to do the conversion and (after testing) replacement of the old version.
You think, I know, is the difference.
But as always Patches cheerfully accepted.
And you *really* need to take this conversation to an RPM list instead.
I'd add the CC, but I have no idea what RPM you wish to use.
73 de Jeff