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

Sat Oct 9 08:15:18 CEST 2010

Marc Paré a écrit :
+>
+> 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.
+The problem is not establishing the current free disk space, but how 
+much to leave for use as temporary disk space for other applications.
+For example, if an enduser likes editing numerous large video files at 
+the same time (maybe he makes movies), he could need a very large amount 
+of temporary free disk space.  Another user, with the same programs 
+installed, might do primarily word processing and Internet, and only 
+occasionally edit small videos, thus only needing a relatively small 
+amount of temporary disk space.
+Of course, there could be an automatic default, adjustable via a 
+configuration file.
+>
+> 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.
+This sort of makes sense -- but it is not only the newly installed 
+program which is of concern, but also other programs which may have the 
+same dependancies (not counting the versions).
+It could take a considerable time before these other programs are 
+executed, so it becomes a bit tricky.
+Probably why Microsoft decided to keep such programs by default.
+
+Essentially that is why I would prefer backports to use versions of 
+dependancies which correspond to the distro release.  A bit more work 
+for packagers, but a much more stable system.
+Then the rollback system would only affect the backported program and 
+any programs directly dependant on that version.  The problem becomes 
+much simpler.
+Once the backported and dependant programs (which would be known in the 
+database) have all been run without crashing, the user could be asked if 
+the programs all worked satifactorily and it was ok to delete the backup.
+
+> 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.
+I definitely like the idea of a rollback option.
+However, another option which I would like to see is simply leaving the 
+old program in place where possible without conflicts - and prompting 
+for its deletion after the backport and dependancies have been run (with 
+the same sort of information displayed) -- when rpmdrake/urpmi is 
+subsequently accessed.
+In the case of problems with the backport, one would simply run the old 
+program, which is still in place.
+Of course, there will often be conficts such that the old program can 
+not be left in place, making rollbacks still useful.
+>
+> Marc
+- André (andre999)
+