diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101008/001021.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101008/001021.html | 183 |
1 files changed, 183 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101008/001021.html b/zarb-ml/mageia-dev/20101008/001021.html new file mode 100644 index 000000000..6c135ecb0 --- /dev/null +++ b/zarb-ml/mageia-dev/20101008/001021.html @@ -0,0 +1,183 @@ +<!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=%3C4CAE5C89.9040501%40roadrunner.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001020.html"> + <LINK REL="Next" HREF="001022.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Proposal: Updating released versions (long post)</H1> + <B>Frank Griffin</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=%3C4CAE5C89.9040501%40roadrunner.com%3E" + TITLE="[Mageia-dev] Proposal: Updating released versions (long post)">ftg at roadrunner.com + </A><BR> + <I>Fri Oct 8 01:49:29 CEST 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001020.html">[Mageia-dev] Talk of Browsers +</A></li> + <LI>Next message: <A HREF="001022.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1021">[ date ]</a> + <a href="thread.html#1021">[ thread ]</a> + <a href="subject.html#1021">[ subject ]</a> + <a href="author.html#1021">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Part of the recent thread about what the desirable release cycle should +be devolved into a discussion of how backports works and whether or not +it's suitable. I'd like to examine this issue. + +The current urpmi repository architecture serves purposes that were +meaningful to Mandriva. It segregates main from contrib for statement +of support reasons, it separates non-free from main for philosophical +reasons, and it separates restricted from main for legal and business +reasons. + +This works pretty well for cooker, where you either want a particular +category of package considered or you don't, but the reuse of this model +for updates, backports, and testing in released versions isn't as good a +fit. + +The root of the problem is that the user base is different. Users of +cooker want the latest and greatest of everything, and have accepted +that if something breaks in cooker, it may stay broken for awhile. +Users of released versions vary all over the map, from people who never +want anything to change to people who want some specific updates to +people who want everything new but want it stable. Users of cooker +rarely think about security updates, because in grabbing everything +available constantly, the security updates are "just there". With users +of released versions, they may have to opt-in for security updates, and +usually want to treat other updates differently. + +I'd like to propose the following model for updating released versions: + +1) Users should not have to see, except in minor ways, the different +repositories. Urpmi may see them, and advanced or ideologically polar +users may care about them (e.g. free vs non-free), but most users +won't. Instead, let urpmi or rpmdrake have knowledge about all +repositories whether enabled or not, and display the offerings with an +icon, tooltip, or extra column that indicates the status of the package. + +2) The update tool we give these users should distinguish between +security updates and backports/testing, but present them both. This is +very much like the Windows Update model, where all available fixes are +divided into "Critical System Updates" and "Software Updates". We don't +really have the same support constraints as Mandriva, and there's no +need to automatically disable backports across the board, and not even +present the backports as possibilities. + +3) Users should be able to enable options for each category +independently. Most users would probably want security updates applied +automatically, but would want to be notified of availability of +backports or testing and choose those manually. + +(Here's the biggie :-) ) +4) We need to enhance the urpmi.recover functionality and bring it fully +into mainstream urpmi so that ANY PACKAGE CAN BE ROLLED BACK TO ITS +PREVIOUS VERSION (sorry for the caps). If we don't want to be stuck +with trying to reconcile our desire to QA some packages better than +others with some users' desires to at least *try* the newest stuff, then +we need to allow them to move forwards and backwards in the package +history as easily as possible. + +Yes, I know this is problematic. It means that we have to do a really +good job of getting dependencies right. But if the dependencies *are* +right, then this should be doable. + +It means that we need to expand the logic in urpmi that can currently +identify the packages that need to be uninstalled if some other package +is uninstalled so that it can take into account the package it will be +installing in its place (and the other older versions of packages that +it will require), and compare the two lists to produce a "diff". + +It needs to decide which changes can be "quiet", e.g. "A" 1.3 requires +"B" 1.3" and "A" 1.2 requires "B" 1.2, so a request to replace "A" 1.3 +with "A" 1.2 would cause a replacement of "B" 1.3 with "B" 1.2 in the +same transaction. This may have a cascading effect. In any event, the +user should be told what's going to be backlevelled, but specifically +*not* see the current urpmi list of everything that will have to be +removed if "A" 1.3 is removed if most of that stuff is simply going to +be replaced with its own previous versions. In other words, rather than +tell the user that removing "A" 1.3 is going to remove half of KDE and +scare the sh*t out of him, just tell him that the following packages are +going to have to be backlevelled as well. If there really are things +that can't be undone and redone, that should be a separate highly +visible prompt. + +This will require some extended transactional support in urpmi, I would +think, because we'd literally have to overrule rpm about pulling stuff +out from under the feet of other packages if we knew we were going to +put it back. That would mean that we'd have the responsibility of +ensuring that the transaction either committed fully from our +perspective, or got fully rolled back. + +This also means that packagers would have to be aware of packages that +reformat their application files as the version increases, and would +have to archive previous versions using some naming scheme so that they +could be restored (and the current version archived) if an uninstall was +requested. Of course, this would require a prompt to the user to inform +him that any configuration changes made since the upgrade would be +lost. We'd probably also have to expand the "rpmnew" concept to be +version-specific. + +Yes, I realize that a couple of clicks could require a *lot* of +processing; but that can happen today, and the user would still get a +prompt about what was going to be done. + +========================= + +If all this were done, updates/backports/testing could be touted as a +"try it" environment. Click on the update(s) you want to try, we'll +tell you what else we're going to have to upgrade as well, and if for +some reason it doesn't work, you click to restore it to version x.x, we +tell you what will also be restored, and we do it. That way, we don't +have to worry about "guaranteeing" perfect quality updates. If we +missed something, and it doesn't work for you, just roll it back. + +This does require access to all previous versions of each package since +release. However, unless we screw up royally on a recurring basis, the +demand for these intermediate packages should be *much* lighter than for +the current versions, so hosting them on a Mageia primary or possibly +the first-tier mirrors should be sufficient. + +It may be that a good implementation of this would require the +availability of significant disk space for translation-related backups +or such, on the root partition or some other designated partition. If +so, we should determine if there is sufficient space, and if not, alert +the user that his choices are to abort the update or else realize that +he won't be able to roll back. Windows XP SPs do this. I don't see a +problem with this, since the current urpmi response to insufficient disk +space is basically to abort the package install but keep going. + +Thoughts ? +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001020.html">[Mageia-dev] Talk of Browsers +</A></li> + <LI>Next message: <A HREF="001022.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1021">[ date ]</a> + <a href="thread.html#1021">[ thread ]</a> + <a href="subject.html#1021">[ subject ]</a> + <a href="author.html#1021">[ 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> |