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)
