diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101009/001053.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101009/001053.html | 210 |
1 files changed, 210 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101009/001053.html b/zarb-ml/mageia-dev/20101009/001053.html new file mode 100644 index 000000000..0e6bc6f46 --- /dev/null +++ b/zarb-ml/mageia-dev/20101009/001053.html @@ -0,0 +1,210 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Proposal: Updating released versions (long post) + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Proposal%3A%20Updating%20released%20versions%20%28long%20post%29&In-Reply-To=%3C20101009080508.39422de1%40otfordduckscomputers.co.uk%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001052.html"> + <LINK REL="Next" HREF="001054.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Proposal: Updating released versions (long post)</H1> + <B>Margot</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Proposal%3A%20Updating%20released%20versions%20%28long%20post%29&In-Reply-To=%3C20101009080508.39422de1%40otfordduckscomputers.co.uk%3E" + TITLE="[Mageia-dev] Proposal: Updating released versions (long post)">margot at otfordduckscomputers.co.uk + </A><BR> + <I>Sat Oct 9 09:05:08 CEST 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001052.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI>Next message: <A HREF="001054.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1053">[ date ]</a> + <a href="thread.html#1053">[ thread ]</a> + <a href="subject.html#1053">[ subject ]</a> + <a href="author.html#1053">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Sat, 09 Oct 2010 02:15:18 -0400 +andré <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">andr55 at laposte.net</A>> wrote: + +><i> Marc Paré a écrit : +</I>><i> > +</I>><i> > Le 2010-10-08 23:45, andré a écrit : +</I>><i> >> Frank Griffin a écrit : +</I>><i> >>> Marc Paré wrote: +</I>><i> >>>> Thanks. So this thread is to see if there were a possibility +</I>><i> >>>> to programme a more efficient roll-back option so that it +</I>><i> >>>> would be more "aware" of the previous "dependencies" needs +</I>><i> >>>> for the previous version. Having "double dependencies" is +</I>><i> >>>> not so much of a problem, it is the rollback to a previous +</I>><i> >>>> version where the dependency confusion may occur, and, ONLY, +</I>><i> >>>> if an upgraded type of "dependency" thread had been +</I>><i> >>>> installed. (Sorry I may have used the wrong terms in the +</I>><i> >>>> last sentence). +</I>><i> >>> Well, sort of. It's not an issue of efficiency, but of +</I>><i> >>> convenience and just making it possible to do without +</I>><i> >>> resorting to manual use of the rpm +</I>><i> >>> command. +</I>><i> >>> +</I>><i> >>> The rpm command "knows" that a new version replacing the old +</I>><i> >>> version supplies the same things that the old one did, so it +</I>><i> >>> will quietly allow the upgrade. It will also do what we need, +</I>><i> >>> i.e. go the other way and replace a newer version with an +</I>><i> >>> older one if you use the --oldpackage keyword. We just need +</I>><i> >>> urpmi to support its use +</I>><i> >> +</I>><i> >> One thing that could facilitate this process, if the computer +</I>><i> >> has a lot of free disk space, is to rename the files being +</I>><i> >> removed (copying the configuration files), instead of erasing +</I>><i> >> them. Although they will probably have to be erased +</I>><i> >> eventually, since no computer has unlimited disk space. +</I>><i> >> Keeping them long enough that a roll-back is no longer +</I>><i> >> probable could be workable. Then a roll-back could be done +</I>><i> >> very quickly, since the files are already on disk, and +</I>><i> >> presumably reliably. Of course, if new data has been entered, +</I>><i> >> and the format has been changed, this could be problematic. +</I>><i> >> Note that configuration files that have been changed from the +</I>><i> >> installation default are often already saved. (Generally +</I>><i> >> ".old" is appended to the configuration file name, sometimes +</I>><i> >> ".new" to the new configuration file.) This of course adds the +</I>><i> >> maintenance task of removing the old files at some point - it +</I>><i> >> could be done automatically according to some criteria, or the +</I>><i> >> user could have to do it manually, perhaps after being +</I>><i> >> prompted about it. +</I>><i> >> +</I>><i> >> (This rollback capability occurs with Microsoft products. The +</I>><i> >> saved files are only removed manually, on user initiative, +</I>><i> >> which partly explains the bloated size of a Microsoft +</I>><i> >> installation over time.) +</I>><i> >> +</I>><i> >> If renaming-instead-of-deleting is implemented, perhaps a "do +</I>><i> >> not keep old program files (useful if limited disk space)" +</I>><i> >> checkbox option would be useful for computers with less free +</I>><i> >> disk space. Of course how much disk space is usable to save +</I>><i> >> old programs on a computer depends on the disk space usage for +</I>><i> >> other purposes over time. +</I>><i> >> +</I>><i> >> my 2 cents :) +</I>><i> >> +</I>><i> >> - André (andre999) +</I>><i> > +</I>><i> > Not sure about this process. Instead of making it easier for a +</I>><i> > user, this would now make it more difficult to do and add +</I>><i> > another layer of knowledge for the new user. It would have to +</I>><i> > be a little more seamless than this. +</I>><i> > +</I>><i> > If there were a way at setup to establish the amount of +</I>><i> > remaining disk space at installation time, and if there were +</I>><i> > enough space to allow rollbacks without compromising the +</I>><i> > installation, then I guess the rollback could then be +</I>><i> > activated. The user could then be advised at this point that +</I>><i> > this was activated. If there was not enought disk space, a +</I>><i> > message could warn the user that software rollbacks would not +</I>><i> > be possible for lack lack of diskspace. +</I>><i> The problem is not establishing the current free disk space, but +</I>><i> how much to leave for use as temporary disk space for other +</I>><i> applications. For example, if an enduser likes editing numerous +</I>><i> large video files at the same time (maybe he makes movies), he +</I>><i> could need a very large amount of temporary free disk space. +</I>><i> Another user, with the same programs installed, might do +</I>><i> primarily word processing and Internet, and only occasionally +</I>><i> edit small videos, thus only needing a relatively small amount of +</I>><i> temporary disk space. Of course, there could be an automatic +</I>><i> default, adjustable via a configuration file. +</I>><i> > +</I>><i> > I guess then, in the MCC, if a user used the Backports and +</I>><i> > installed backported software, the rollback amount of diskspace +</I>><i> > could also be monitored at this level with perhaps an option to +</I>><i> > delete old programs that are now working well in their updated +</I>><i> > form. +</I>><i> This sort of makes sense -- but it is not only the newly +</I>><i> installed program which is of concern, but also other programs +</I>><i> which may have the same dependancies (not counting the versions). +</I>><i> It could take a considerable time before these other programs are +</I>><i> executed, so it becomes a bit tricky. +</I>><i> Probably why Microsoft decided to keep such programs by default. +</I>><i> +</I>><i> Essentially that is why I would prefer backports to use versions +</I>><i> of dependancies which correspond to the distro release. A bit +</I>><i> more work for packagers, but a much more stable system. +</I>><i> Then the rollback system would only affect the backported program +</I>><i> and any programs directly dependant on that version. The problem +</I>><i> becomes much simpler. +</I>><i> Once the backported and dependant programs (which would be known +</I>><i> in the database) have all been run without crashing, the user +</I>><i> could be asked if the programs all worked satifactorily and it +</I>><i> was ok to delete the backup. +</I>><i> +</I>><i> > I guess this would take a bit of coding. But at least the use +</I>><i> > of Backports would make a little more sense with a rollback +</I>><i> > option in case an updated software installation did not work +</I>><i> > out. +</I>><i> I definitely like the idea of a rollback option. +</I>><i> However, another option which I would like to see is simply +</I>><i> leaving the old program in place where possible without conflicts +</I>><i> - and prompting for its deletion after the backport and +</I>><i> dependancies have been run (with the same sort of information +</I>><i> displayed) -- when rpmdrake/urpmi is subsequently accessed. +</I>><i> In the case of problems with the backport, one would simply run +</I>><i> the old program, which is still in place. +</I>><i> Of course, there will often be conficts such that the old program +</I>><i> can not be left in place, making rollbacks still useful. +</I>><i> > +</I>><i> > Marc +</I>><i> - André (andre999) +</I> +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! +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001052.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI>Next message: <A HREF="001054.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1053">[ date ]</a> + <a href="thread.html#1053">[ thread ]</a> + <a href="subject.html#1053">[ subject ]</a> + <a href="author.html#1053">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |