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)
