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

[Margot]

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!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~