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

Sat Oct 9 09:05:08 CEST 2010

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.
+
+-- 
+Margot
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
+**Otford Ducks Computers**
+We teach, you learn...
+...and, if you don't do your homework, we set the cat on you!
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+