[Mageia-dev] Proposal: Updating released versions (long post)

[Marc Paré]

Le 2010-10-08 16:32, Frank Griffin a écrit :
> Marc Paré wrote:
>>
>> So, in terms of space used for this, if you had to install all 6,
>> would this tax the system so much and risk filling up the hardrive
>> needlessly.
>
> Not really, since the old versions would be removed when the new ones
> were installed.  The behavior I described is not part of the proposal;
> that's what happens today.
>
>>
>> It not, if a rollback were done, could all 6 as well as the new F be
>> removed and the old version restored?
>
> Yes, that's exactly what happens today.The problem is that today,
> removing them may cause tons of other packages to have to be removed
> because they require things that A-F provide.  This wasn't a problem on
> upgrade, because the removal of the old and the addition of the new was
> a single urpmi "transaction" (I put this in quotes because urpmi uses
> "transaction" to mean something other than what I mean here), and urpmi
> "knew" that the new versions supplied all the things that vanished when
> the old versions were removed.  Today, rollbacks have to be done
> manually - remove new, then install old.  Urpmi doesn't know at the time
> of the removal that you're going to turn around and install the old
> versions next.  It only sees that all the things that both the old and
> new versions supply are about to disappear from your system, so it tells
> you that you have to remove any other package which requires those things.
>>
>> If this is possible, would this have an impact on devs preparing
>> Backport versions with rollbacks?
>
> RPM dependencies aren't a problem.  Urpmi/urpme know all about them.
> The only packaging changes would be for situations like that where a new
> version of an application has changed a format of one of its files in
> your home directory and the new version automatically converts the old
> version of the file to the new format.  In that case, the package would
> need install scriptlets that copied the old version somewhere so that it
> could be restored at uninstall time, otherwise the old version of the
> software won't be able to use the new file format.
>
> The biggest chunk of development involved in the proposal is to make
> urpmi do a rollback as a single operation, just as it does an upgrade.
> This already exists, in a way; there is a facility called urpmi.recover
> that does this type of thing.  Bit it's not really considered
> mainstream, and I don't think it's been supported for a while.
>
>

Thanks. So this thread is to see if there were a possibility to 
programme a more efficient roll-back option so that it would be more 
"aware" of the previous "dependencies" needs for the previous version. 
Having "double dependencies" is not so much of a problem, it is the 
rollback to a previous version where the dependency confusion may occur, 
and, ONLY, if an upgraded type of "dependency" thread had been 
installed. (Sorry I may have used the wrong terms in the last sentence).

Marc