diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101008/001022.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101008/001022.html | 229 |
1 files changed, 229 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101008/001022.html b/zarb-ml/mageia-dev/20101008/001022.html new file mode 100644 index 000000000..47be1df6c --- /dev/null +++ b/zarb-ml/mageia-dev/20101008/001022.html @@ -0,0 +1,229 @@ +<!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=%3Ci8ls6o%2434h%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="001021.html"> + <LINK REL="Next" HREF="001032.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=%3Ci8ls6o%2434h%241%40dough.gmane.org%3E" + TITLE="[Mageia-dev] Proposal: Updating released versions (long post)">marc at marcpare.com + </A><BR> + <I>Fri Oct 8 03:29:59 CEST 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001021.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI>Next message: <A HREF="001032.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1022">[ date ]</a> + <a href="thread.html#1022">[ thread ]</a> + <a href="subject.html#1022">[ subject ]</a> + <a href="author.html#1022">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le 2010-10-07 19:49, Frank Griffin a écrit : +><i> Part of the recent thread about what the desirable release cycle should +</I>><i> be devolved into a discussion of how backports works and whether or not +</I>><i> it's suitable. I'd like to examine this issue. +</I>><i> +</I>><i> The current urpmi repository architecture serves purposes that were +</I>><i> meaningful to Mandriva. It segregates main from contrib for statement +</I>><i> of support reasons, it separates non-free from main for philosophical +</I>><i> reasons, and it separates restricted from main for legal and business +</I>><i> reasons. +</I>><i> +</I>><i> This works pretty well for cooker, where you either want a particular +</I>><i> category of package considered or you don't, but the reuse of this model +</I>><i> for updates, backports, and testing in released versions isn't as good a +</I>><i> fit. +</I>><i> +</I>><i> The root of the problem is that the user base is different. Users of +</I>><i> cooker want the latest and greatest of everything, and have accepted +</I>><i> that if something breaks in cooker, it may stay broken for awhile. +</I>><i> Users of released versions vary all over the map, from people who never +</I>><i> want anything to change to people who want some specific updates to +</I>><i> people who want everything new but want it stable. Users of cooker +</I>><i> rarely think about security updates, because in grabbing everything +</I>><i> available constantly, the security updates are "just there". With users +</I>><i> of released versions, they may have to opt-in for security updates, and +</I>><i> usually want to treat other updates differently. +</I>><i> +</I>><i> I'd like to propose the following model for updating released versions: +</I>><i> +</I>><i> 1) Users should not have to see, except in minor ways, the different +</I>><i> repositories. Urpmi may see them, and advanced or ideologically polar +</I>><i> users may care about them (e.g. free vs non-free), but most users +</I>><i> won't. Instead, let urpmi or rpmdrake have knowledge about all +</I>><i> repositories whether enabled or not, and display the offerings with an +</I>><i> icon, tooltip, or extra column that indicates the status of the package. +</I>><i> +</I>><i> 2) The update tool we give these users should distinguish between +</I>><i> security updates and backports/testing, but present them both. This is +</I>><i> very much like the Windows Update model, where all available fixes are +</I>><i> divided into "Critical System Updates" and "Software Updates". We don't +</I>><i> really have the same support constraints as Mandriva, and there's no +</I>><i> need to automatically disable backports across the board, and not even +</I>><i> present the backports as possibilities. +</I>><i> +</I>><i> 3) Users should be able to enable options for each category +</I>><i> independently. Most users would probably want security updates applied +</I>><i> automatically, but would want to be notified of availability of +</I>><i> backports or testing and choose those manually. +</I>><i> +</I>><i> (Here's the biggie :-) ) +</I>><i> 4) We need to enhance the urpmi.recover functionality and bring it fully +</I>><i> into mainstream urpmi so that ANY PACKAGE CAN BE ROLLED BACK TO ITS +</I>><i> PREVIOUS VERSION (sorry for the caps). If we don't want to be stuck +</I>><i> with trying to reconcile our desire to QA some packages better than +</I>><i> others with some users' desires to at least *try* the newest stuff, then +</I>><i> we need to allow them to move forwards and backwards in the package +</I>><i> history as easily as possible. +</I>><i> +</I>><i> Yes, I know this is problematic. It means that we have to do a really +</I>><i> good job of getting dependencies right. But if the dependencies *are* +</I>><i> right, then this should be doable. +</I>><i> +</I>><i> It means that we need to expand the logic in urpmi that can currently +</I>><i> identify the packages that need to be uninstalled if some other package +</I>><i> is uninstalled so that it can take into account the package it will be +</I>><i> installing in its place (and the other older versions of packages that +</I>><i> it will require), and compare the two lists to produce a "diff". +</I>><i> +</I>><i> It needs to decide which changes can be "quiet", e.g. "A" 1.3 requires +</I>><i> "B" 1.3" and "A" 1.2 requires "B" 1.2, so a request to replace "A" 1.3 +</I>><i> with "A" 1.2 would cause a replacement of "B" 1.3 with "B" 1.2 in the +</I>><i> same transaction. This may have a cascading effect. In any event, the +</I>><i> user should be told what's going to be backlevelled, but specifically +</I>><i> *not* see the current urpmi list of everything that will have to be +</I>><i> removed if "A" 1.3 is removed if most of that stuff is simply going to +</I>><i> be replaced with its own previous versions. In other words, rather than +</I>><i> tell the user that removing "A" 1.3 is going to remove half of KDE and +</I>><i> scare the sh*t out of him, just tell him that the following packages are +</I>><i> going to have to be backlevelled as well. If there really are things +</I>><i> that can't be undone and redone, that should be a separate highly +</I>><i> visible prompt. +</I>><i> +</I>><i> This will require some extended transactional support in urpmi, I would +</I>><i> think, because we'd literally have to overrule rpm about pulling stuff +</I>><i> out from under the feet of other packages if we knew we were going to +</I>><i> put it back. That would mean that we'd have the responsibility of +</I>><i> ensuring that the transaction either committed fully from our +</I>><i> perspective, or got fully rolled back. +</I>><i> +</I>><i> This also means that packagers would have to be aware of packages that +</I>><i> reformat their application files as the version increases, and would +</I>><i> have to archive previous versions using some naming scheme so that they +</I>><i> could be restored (and the current version archived) if an uninstall was +</I>><i> requested. Of course, this would require a prompt to the user to inform +</I>><i> him that any configuration changes made since the upgrade would be +</I>><i> lost. We'd probably also have to expand the "rpmnew" concept to be +</I>><i> version-specific. +</I>><i> +</I>><i> Yes, I realize that a couple of clicks could require a *lot* of +</I>><i> processing; but that can happen today, and the user would still get a +</I>><i> prompt about what was going to be done. +</I>><i> +</I>><i> ========================= +</I>><i> +</I>><i> If all this were done, updates/backports/testing could be touted as a +</I>><i> "try it" environment. Click on the update(s) you want to try, we'll +</I>><i> tell you what else we're going to have to upgrade as well, and if for +</I>><i> some reason it doesn't work, you click to restore it to version x.x, we +</I>><i> tell you what will also be restored, and we do it. That way, we don't +</I>><i> have to worry about "guaranteeing" perfect quality updates. If we +</I>><i> missed something, and it doesn't work for you, just roll it back. +</I>><i> +</I>><i> This does require access to all previous versions of each package since +</I>><i> release. However, unless we screw up royally on a recurring basis, the +</I>><i> demand for these intermediate packages should be *much* lighter than for +</I>><i> the current versions, so hosting them on a Mageia primary or possibly +</I>><i> the first-tier mirrors should be sufficient. +</I>><i> +</I>><i> It may be that a good implementation of this would require the +</I>><i> availability of significant disk space for translation-related backups +</I>><i> or such, on the root partition or some other designated partition. If +</I>><i> so, we should determine if there is sufficient space, and if not, alert +</I>><i> the user that his choices are to abort the update or else realize that +</I>><i> he won't be able to roll back. Windows XP SPs do this. I don't see a +</I>><i> problem with this, since the current urpmi response to insufficient disk +</I>><i> space is basically to abort the package install but keep going. +</I>><i> +</I>><i> Thoughts ? +</I>><i> +</I> +Hi FranK: + +As it seems we keep going in circles on this Romain has arranged the +following so that the threads on this topic become more focussed: + +-------------- + +It has been posted before but I guess it's a good read for anyone +willing to push an argument in this debate: +<A HREF="http://mairin.wordpress.com/2010/09/01/a-story-about-updates-and-people/">http://mairin.wordpress.com/2010/09/01/a-story-about-updates-and-people/</A> + +It is a nice post explaining the existing different point of views +(bonus to clever points about updates frequency and presentation). + +Now, in the same vein, let's put the discussion at rest a little and +have each interested person write down an article with arguments for +the why's and how's. So here is a page for that: +<A HREF="http://mageia.org/wiki/doku.php?id=rollingdebate">http://mageia.org/wiki/doku.php?id=rollingdebate</A> + +Please write down your point of view, detail it as explained on the +wiki page, link it and a week from now, everyone involved in the +discussion can have a look at it for a summary. + +That won't trigger a change decision at once (way too soon anyway, we +have to roll a first release to assess our new build system and +infrastructure and organisation) but it may at least lay down all +arguments and allow to have a better view of what everyone understand, +agree on definitions and see what is really at stake here. For later +reference, discussion and decision. + +Thanks a lot. + +Cheers, + +Romain + +-------------- + +Marc + + +</PRE> + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001021.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI>Next message: <A HREF="001032.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1022">[ date ]</a> + <a href="thread.html#1022">[ thread ]</a> + <a href="subject.html#1022">[ subject ]</a> + <a href="author.html#1022">[ 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> |