Jeff Johnson wrote:
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).
Co-existing, as in being stored somewhere isn't quite the point. They both have to be able to be run, find the correct libraries, etc, and the one currently known to work has to be found by other applications.
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.
But RPM can't do it unless it can always succeed with no user/admin input. I don't believe that's possible.
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.
But you can't replace my current old files with new ones of the same name until you know they work. And you can't know that they work because you don't know what applications I have.
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?
Sure, if it is something like running a script, testing an app known not to work with 8.3 (I think some versions of OpenNMS would qualify) and then seeing if the back-out strategy works.
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.
That's why I want the conversion to be scripted.
But as always Patches cheerfully accepted.
And you *really* need to take this conversation to an RPM list instead.
It really doesn't have much to do with RPM. It has to do with naming the replacement files so they don't overwrite the things that have to remain.