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.
--
Les Mikesell
lesmikesell at gmail.com