On Sat, 09 Oct 2010 02:15:18 -0400 andré <[email protected]> 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! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
