[Mageia-dev] Proposal: Updating released versions (long post)
marc at marcpare.com
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
>>>>> 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
>> 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
>> 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.
>> - 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
> 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.
More information about the Mageia-dev