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

Sat Oct 9 09:12:39 CEST 2010

Le 2010-10-09 03:05, Margot a écrit :
+> On Sat, 09 Oct 2010 02:15:18 -0400
+> andré<andr55 at laposte.net>  wrote:
+>
+>> 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)
+>
+> There are already various options which can be run with urpmi, such
+> as --noclean and --repackage (see man urpmi) and perhaps these
+> could be incorporated into the GUI - with full simple explanations
+> for the user on exactly what will happen if those options are
+> chosen.
+>
+> For example:
+> "Select this option if you want to save the old version of the
+> package that is being updated. If there is a problem with the new
+> version, you will be able to uninstall it and go back to the older
+> version. Warning: this option will use extra space on your disk."
+>
+> There could then be a list available showing all the saved older
+> versions of packages - if, for instance, a user had saved 10 older
+> versions of Firefox and knew that the most recent one worked
+> perfectly, they could then safely delete the 9 older versions to
+> reclaim some disk space.
+>
+
+I guess both of your suggestions would work André and Margot.
+
+So, this sounds like it could be something that could be worked out. I 
+would prefer, as a user, Margot's process. Of course the user would have 
+to be able to see the usage and re-claimed space due to his use or 
+Backports. Just to keep informed.
+
+Marc
+
+