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

Fri Oct 8 22:49:01 CEST 2010

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
+
+