diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101009/001063.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101009/001063.html | 155 |
1 files changed, 155 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101009/001063.html b/zarb-ml/mageia-dev/20101009/001063.html new file mode 100644 index 000000000..97045db1b --- /dev/null +++ b/zarb-ml/mageia-dev/20101009/001063.html @@ -0,0 +1,155 @@ +<!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=%3C4CB07F16.2000203%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001057.html"> + <LINK REL="Next" HREF="001064.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=%3C4CB07F16.2000203%40laposte.net%3E" + TITLE="[Mageia-dev] Proposal: Updating released versions (long post)">andr55 at laposte.net + </A><BR> + <I>Sat Oct 9 16:41:26 CEST 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001057.html">[Mageia-dev] Release cycle - what is actually POSSIBLE? +</A></li> + <LI>Next message: <A HREF="001064.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1063">[ date ]</a> + <a href="thread.html#1063">[ thread ]</a> + <a href="subject.html#1063">[ subject ]</a> + <a href="author.html#1063">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>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>But wouldn't most users of cooker just take some packages from cooker to +install on their stable release ? Even if it's a computer used only for +testing purposes ? +><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>Lets assume that the GUI rpmdrake is used. +Instead of hiding the repositories (or partially hiding them as now done), +let's display the current selection on entering rpmdrake, BEFORE taking +the time to load and analyse the list of packages installed and +available on the selected repositories. +Add a checkbox to update for each repository. +They should be listed with a brief description, or have a description +available with context help. +The user then adjusts the selection as desired, before the loading/analysis. +If the user doesn't want to change the selection, they just press return. +Quick, easy - and the user always knows the options available and what +is selected. +And indeed, in the package list displayed it would be useful to have a +column for the source repository. +><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>With a column displaying the source repository, only an option to +display updates is necessary, instead of the current "all updates", +"security updates", "correction of anomolies", and "general updates". +I would keep backports separate, as they are necessarily more problematic. +However I would make the remaining display options with checkboxes : +all, meta packages, graphic applications, updates, and backports. +as well, I would add all/installed/non-installed options to each line. +All these options to remember the last selection, for ease of use. +This way, the user sees all the display options in an easy to follow table. +><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>For automatic selection of packages to install, that is how it works +now, which is fine. But the user should always have the option to +override the automatic selection. + +For example, gedit, the gnome default editor has an extention where the +latest version doesn't work properly for my purposes. An automatic +update installs the newer version, every time there is any type of +update to gedit. I had to use certain options of the command-line tool +to override this to reinstall the working version. And have to ensure +that the non-working extension is not installed during updates. + +BTW, a feature to blacklist the installation of a particular version of +a package would be very useful. I.e. an option "never install this +package" or "never select automatically this package". +This would prevent a package found to be problematic on a particular +system from being accidentally later installed on the system in question. + +- André (andre999) +</PRE> + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001057.html">[Mageia-dev] Release cycle - what is actually POSSIBLE? +</A></li> + <LI>Next message: <A HREF="001064.html">[Mageia-dev] Proposal: Updating released versions (long post) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1063">[ date ]</a> + <a href="thread.html#1063">[ thread ]</a> + <a href="subject.html#1063">[ subject ]</a> + <a href="author.html#1063">[ 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> |