diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101009/001052.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101009/001052.html | 172 |
1 files changed, 172 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101009/001052.html b/zarb-ml/mageia-dev/20101009/001052.html new file mode 100644 index 000000000..5e9c17b72 --- /dev/null +++ b/zarb-ml/mageia-dev/20101009/001052.html @@ -0,0 +1,172 @@ +<!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=%3C4CB00876.9070001%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001051.html"> + <LINK REL="Next" HREF="001053.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Proposal: Updating released versions (long post)</H1> + <B>andré</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=%3C4CB00876.9070001%40laposte.net%3E" + TITLE="[Mageia-dev] Proposal: Updating released versions (long post)">andr55 at laposte.net + </A><BR> + <I>Sat Oct 9 08:15:18 CEST 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001051.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI>Next message: <A HREF="001053.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1052">[ date ]</a> + <a href="thread.html#1052">[ thread ]</a> + <a href="subject.html#1052">[ subject ]</a> + <a href="author.html#1052">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Marc Paré a écrit : +><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 to +</I>>>>><i> programme a more efficient roll-back option so that it would be more +</I>>>>><i> "aware" of the previous "dependencies" needs for the previous version. +</I>>>>><i> Having "double dependencies" is not so much of a problem, it is the +</I>>>>><i> rollback to a previous version where the dependency confusion may +</I>>>>><i> occur, and, ONLY, if an upgraded type of "dependency" thread had been +</I>>>>><i> installed. (Sorry I may have used the wrong terms in the last +</I>>>>><i> sentence). +</I>>>><i> Well, sort of. It's not an issue of efficiency, but of convenience and +</I>>>><i> just making it possible to do without resorting to manual use of the +</I>>>><i> rpm +</I>>>><i> command. +</I>>>><i> +</I>>>><i> The rpm command "knows" that a new version replacing the old version +</I>>>><i> supplies the same things that the old one did, so it will quietly allow +</I>>>><i> the upgrade. It will also do what we need, i.e. go the other way and +</I>>>><i> replace a newer version with an older one if you use the --oldpackage +</I>>>><i> keyword. We just need urpmi to support its use +</I>>><i> +</I>>><i> One thing that could facilitate this process, if the computer has a lot +</I>>><i> of free disk space, is to rename the files being removed (copying the +</I>>><i> configuration files), instead of erasing them. Although they will +</I>>><i> probably have to be erased eventually, since no computer has unlimited +</I>>><i> disk space. Keeping them long enough that a roll-back is no longer +</I>>><i> probable could be workable. +</I>>><i> Then a roll-back could be done very quickly, since the files are already +</I>>><i> on disk, and presumably reliably. Of course, if new data has been +</I>>><i> entered, 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 ".old" is +</I>>><i> appended to the configuration file name, sometimes ".new" to the new +</I>>><i> configuration file.) +</I>>><i> This of course adds the maintenance task of removing the old files at +</I>>><i> some point - it could be done automatically according to some criteria, +</I>>><i> or the user could have to do it manually, perhaps after being prompted +</I>>><i> about it. +</I>>><i> +</I>>><i> (This rollback capability occurs with Microsoft products. The saved +</I>>><i> files are only removed manually, on user initiative, which partly +</I>>><i> explains the bloated size of a Microsoft installation over time.) +</I>>><i> +</I>>><i> If renaming-instead-of-deleting is implemented, perhaps a "do not keep +</I>>><i> old program files (useful if limited disk space)" checkbox option would +</I>>><i> be useful for computers with less free disk space. +</I>>><i> Of course how much disk space is usable to save old programs on a +</I>>><i> computer depends on the disk space usage for 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 user, +</I>><i> this would now make it more difficult to do and add another layer of +</I>><i> knowledge for the new user. It would have to be a little more seamless +</I>><i> than this. +</I>><i> +</I>><i> If there were a way at setup to establish the amount of remaining disk +</I>><i> space at installation time, and if there were enough space to allow +</I>><i> rollbacks without compromising the installation, then I guess the +</I>><i> rollback could then be activated. The user could then be advised at +</I>><i> this point that this was activated. If there was not enought disk +</I>><i> space, a message could warn the user that software rollbacks would not +</I>><i> be possible for lack lack of diskspace. +</I>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> +</I>><i> I guess then, in the MCC, if a user used the Backports and installed +</I>><i> backported software, the rollback amount of diskspace could also be +</I>><i> monitored at this level with perhaps an option to delete old programs +</I>><i> that are now working well in their updated form. +</I>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> I guess this would take a bit of coding. But at least the use of +</I>><i> Backports would make a little more sense with a rollback option in +</I>><i> case an updated software installation did not work out. +</I>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. +><i> +</I>><i> Marc +</I>- André (andre999) +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001051.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI>Next message: <A HREF="001053.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1052">[ date ]</a> + <a href="thread.html#1052">[ thread ]</a> + <a href="subject.html#1052">[ subject ]</a> + <a href="author.html#1052">[ 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> |