diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101009/001054.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101009/001054.html | 217 |
1 files changed, 217 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101009/001054.html b/zarb-ml/mageia-dev/20101009/001054.html new file mode 100644 index 000000000..db6fdb099 --- /dev/null +++ b/zarb-ml/mageia-dev/20101009/001054.html @@ -0,0 +1,217 @@ +<!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=%3Ci8p4l8%241b9%241%40dough.gmane.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001053.html"> + <LINK REL="Next" HREF="001070.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Proposal: Updating released versions (long post)</H1> + <B>Marc Paré</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=%3Ci8p4l8%241b9%241%40dough.gmane.org%3E" + TITLE="[Mageia-dev] Proposal: Updating released versions (long post)">marc at marcpare.com + </A><BR> + <I>Sat Oct 9 09:12:39 CEST 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001053.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI>Next message: <A HREF="001070.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1054">[ date ]</a> + <a href="thread.html#1054">[ thread ]</a> + <a href="subject.html#1054">[ subject ]</a> + <a href="author.html#1054">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le 2010-10-09 03:05, Margot a écrit : +><i> On Sat, 09 Oct 2010 02:15:18 -0400 +</I>><i> andré<<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">andr55 at laposte.net</A>> wrote: +</I>><i> +</I>>><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>><i> +</I>><i> There are already various options which can be run with urpmi, such +</I>><i> as --noclean and --repackage (see man urpmi) and perhaps these +</I>><i> could be incorporated into the GUI - with full simple explanations +</I>><i> for the user on exactly what will happen if those options are +</I>><i> chosen. +</I>><i> +</I>><i> For example: +</I>><i> "Select this option if you want to save the old version of the +</I>><i> package that is being updated. If there is a problem with the new +</I>><i> version, you will be able to uninstall it and go back to the older +</I>><i> version. Warning: this option will use extra space on your disk." +</I>><i> +</I>><i> There could then be a list available showing all the saved older +</I>><i> versions of packages - if, for instance, a user had saved 10 older +</I>><i> versions of Firefox and knew that the most recent one worked +</I>><i> perfectly, they could then safely delete the 9 older versions to +</I>><i> reclaim some disk space. +</I>><i> +</I> +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. + +Marc + +</PRE> + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001053.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI>Next message: <A HREF="001070.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1054">[ date ]</a> + <a href="thread.html#1054">[ thread ]</a> + <a href="subject.html#1054">[ subject ]</a> + <a href="author.html#1054">[ 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> |