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

Sat Oct 9 06:37:15 CEST 2010

Le 2010-10-08 23:45, andré a écrit :
+> Frank Griffin a écrit :
+>> Marc Paré wrote:
+>>> 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).
+>> Well, sort of. It's not an issue of efficiency, but of convenience and
+>> just making it possible to do without resorting to manual use of the rpm
+>> command.
+>>
+>> The rpm command "knows" that a new version replacing the old version
+>> supplies the same things that the old one did, so it will quietly allow
+>> the upgrade. It will also do what we need, i.e. go the other way and
+>> replace a newer version with an older one if you use the --oldpackage
+>> keyword. We just need urpmi to support its use
+>
+> One thing that could facilitate this process, if the computer has a lot
+> of free disk space, is to rename the files being removed (copying the
+> configuration files), instead of erasing them. Although they will
+> probably have to be erased eventually, since no computer has unlimited
+> disk space. Keeping them long enough that a roll-back is no longer
+> probable could be workable.
+> Then a roll-back could be done very quickly, since the files are already
+> on disk, and presumably reliably. Of course, if new data has been
+> entered, and the format has been changed, this could be problematic.
+> Note that configuration files that have been changed from the
+> installation default are often already saved. (Generally ".old" is
+> appended to the configuration file name, sometimes ".new" to the new
+> configuration file.)
+> This of course adds the maintenance task of removing the old files at
+> some point - it could be done automatically according to some criteria,
+> or the user could have to do it manually, perhaps after being prompted
+> about it.
+>
+> (This rollback capability occurs with Microsoft products. The saved
+> files are only removed manually, on user initiative, which partly
+> explains the bloated size of a Microsoft installation over time.)
+>
+> If renaming-instead-of-deleting is implemented, perhaps a "do not keep
+> old program files (useful if limited disk space)" checkbox option would
+> be useful for computers with less free disk space.
+> Of course how much disk space is usable to save old programs on a
+> computer depends on the disk space usage for other purposes over time.
+>
+> my 2 cents :)
+>
+> - André (andre999)
+>
+>
+
+Not sure about this process. Instead of making it easier for a user, 
+this would now make it more difficult to do and add another layer of 
+knowledge for the new user. It would have to be a little more seamless 
+than this.
+
+If there were a way at setup to establish the amount of remaining disk 
+space at installation time, and if there were enough space to allow 
+rollbacks without compromising the installation, then I guess the 
+rollback could then be activated. The user could then be advised at this 
+point that this was activated. If there was not enought disk space, a 
+message could warn the user that software rollbacks would not be 
+possible for lack lack of diskspace.
+
+I guess then, in the MCC, if a user used the Backports and installed 
+backported software, the rollback amount of diskspace could also be 
+monitored at this level with perhaps an option to delete old programs 
+that are now working well in their updated form.
+
+I guess this would take a bit of coding. But at least the use of 
+Backports would make a little more sense with a rollback option in case 
+an updated software installation did not work out.
+
+Marc
+
+