diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2012-June/016567.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2012-June/016567.html | 181 |
1 files changed, 181 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-June/016567.html b/zarb-ml/mageia-dev/2012-June/016567.html new file mode 100644 index 000000000..dc7a91481 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-June/016567.html @@ -0,0 +1,181 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Backports policy clarification (and discussion) + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Backports%20policy%20clarification%20%28and%20discussion%29&In-Reply-To=%3Cmv90b9-55e.ln1%40psd.motzarella.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="016428.html"> + <LINK REL="Next" HREF="016303.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Backports policy clarification (and discussion)</H1> + <B>blind Pete</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Backports%20policy%20clarification%20%28and%20discussion%29&In-Reply-To=%3Cmv90b9-55e.ln1%40psd.motzarella.org%3E" + TITLE="[Mageia-dev] Backports policy clarification (and discussion)">0123peter at gmail.com + </A><BR> + <I>Sun Jun 17 08:27:34 CEST 2012</I> + <P><UL> + <LI>Previous message: <A HREF="016428.html">[Mageia-dev] Backports policy clarification (and discussion) +</A></li> + <LI>Next message: <A HREF="016303.html">[Mageia-dev] Backports policy clarification (and discussion) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#16567">[ date ]</a> + <a href="thread.html#16567">[ thread ]</a> + <a href="subject.html#16567">[ subject ]</a> + <a href="author.html#16567">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>andre999 wrote: + +><i> blind Pete a écrit : +</I>>><i> andre999 wrote: +</I>>><i> +</I>>><i> +</I>>>><i> blind Pete a écrit : +</I>>>><i> +</I>>>>><i> Samuel Verschelde wrote: +</I>>>>><i> +</I>>>>><i> +</I>>>>><i> +</I>>>>>><i> Le vendredi 8 juin 2012 20:20:54, David W. Hodgins a écrit : +</I>>>>>><i> +</I>>>>>><i> +</I>>>>>>><i> On Fri, 08 Jun 2012 10:22:41 -0400, Samuel Verschelde +</I>>>>>>><i> <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">stormi at laposte.net</A>> +</I>>>>>>><i> +</I>>>>>>><i> +</I>>>>>><i> wrote: +</I>>>>>><i> +</I>>>>>><i> +</I>>>>>>>><i> I think you missed my point. If Mageia 1 "backports" has higher +</I>>>>>>>><i> versions than Mageia 2 "release" (not backports), upgrade can fail +</I>>>>>>>><i> because currently our tools do not take backports from the target +</I>>>>>>>><i> release (mageia 2) into account when upgrading a distro. +</I>>>>>>>><i> +</I>>>>>>>><i> +</I>>>>>>><i> In the upgrade from Mandriva 2010.2 to Mageia 1, it was made clear, +</I>>>>>>><i> that +</I>>>>>>><i> upgrading from a system with 2010.2 Backports was not supported. It +</I>>>>>>><i> may work, but was not recommended. +</I>>>>>>><i> +</I>>>>>>><i> I think we should keep the same policy for the upgrade from Mageia 1 +</I>>>>>>><i> to 2. +</I>>>>>>><i> I.E. Don't use backports if you are planning on later doing an +</I>>>>>>><i> upgrade, rather then a clean install. +</I>>>>>>><i> +</I>>>>>>><i> That way, Mageia 1 users who want firefox 13 can get it, without us +</I>>>>>>><i> having to replace the Mageia 2 iso images with an upgraded installer, +</I>>>>>>><i> that will keep backports enabled for 2, if it was enabled for 1. +</I>>>>>>><i> +</I>>>>>>><i> +</I>>>><i> Current tools will correctly update backports much of the time. (From +</I>>>><i> my experience.) +</I>>>><i> The tools just need to be reworked somewhat to ensure that backports are +</I>>>><i> updated correctly all of the time. +</I>>>><i> +</I>>>><i> +</I>>>>>>><i> Regards, Dave Hodgins +</I>>>>>>><i> +</I>>>>>>><i> +</I>>>>>><i> Again, this is not the policy we adopted. When we defined the +</I>>>>>><i> backports policy (together, although it seems most people are just +</I>>>>>><i> discovering it now) we said that we didn't want to have backports that +</I>>>>>><i> don't work, break a system, or prevent upgrade. +</I>>>>>><i> +</I>>>>>><i> However, I think that for DVD upgrade without internet access this is +</I>>>>>><i> a sensible option. But the upgrader should detect the situation +</I>>>>>><i> itself, not hope that the user will read somewhere in the release +</I>>>>>><i> notes that it's not supported. +</I>>>>>><i> +</I>>>>>><i> +</I>>>>><i> No, just include Cauldron's backport repositories (disabled by default) +</I>>>>><i> inside the DVD iso. Upgrade to the release version, if possible. +</I>>>>><i> If that is not possible, upgrade to the version in backports. +</I>>>>><i> +</I>>>><i> Cauldron's backport repos will always be empty. +</I>>>><i> If you introduce a new package, or a new version of an existing package +</I>>>><i> to Cauldron, it is not, by definition, a backport. Even though the same +</I>>>><i> version (not counting the revision) may be a backport for previous +</I>>>><i> releases. +</I>>>><i> +</I>>><i> By definition you are completely correct, but I was deliberatly +</I>>><i> bending the definition to cover beta software. Or at least to +</I>>><i> draw a distinction between an Extended Support Release package +</I>>><i> and a standard package. A new name would make sense here. +</I>><i> +</I>><i> They would have different names (if generally only the version included +</I>><i> in one). +</I>><i> Since a backport can only have one name, it would correspond to only one +</I>><i> of the packages. Presumably that with the same (or closest) version. +</I>><i> +</I>>>><i> So if we do a release update to the latest release, backports will be +</I>>>><i> replaced by regular packages except in those cases where a newer version +</I>>>><i> has been introduced into Cauldron. And if we update to Cauldron, all +</I>>>><i> backports will be replaced by regular packages -- according to our +</I>>>><i> backport policy. +</I>>>><i> +</I>>><i> [snip] +</I>>><i> +</I>>><i> Some packages annoyingly have two current versions. When that +</I>>><i> happens it seems perfectly reasonable to just pick one, but if +</I>>><i> anyone is ambitious enough to try two at once, this would be a +</I>>><i> mechanism to handle it. +</I>><i> +</I>><i> Don't see how backport repos are related. +</I>><i> To be installed simultaneously, they would have to install to different +</I>><i> locations, which is generally not the case. There is more than one +</I>><i> version of Postgresql available, for example, but they conflict and so +</I>><i> can't be installed at the same time. +</I> +Not installed simultaneously, but exist simultaneously. +Firefox and Chromium-browser are the bad examples that spring to mind. + +$urpmq -Y chromium-browser- | sort | uniq +chromium-browser +chromium-browser-beta +chromium-browser-stable +chromium-browser-unstable +$urpmq -ia chromium-browser- | grep Version | sort | uniq + $MIRRORLIST: media/core/updates/media_info/20120610-144059-info.xml.lzma +Version : 12.0.742.53 +Version : 13.0.761.0 +Version : 18.0.1025.168 +$ + +-- +blind Pete +Sig goes here... + +</PRE> + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="016428.html">[Mageia-dev] Backports policy clarification (and discussion) +</A></li> + <LI>Next message: <A HREF="016303.html">[Mageia-dev] Backports policy clarification (and discussion) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#16567">[ date ]</a> + <a href="thread.html#16567">[ thread ]</a> + <a href="subject.html#16567">[ subject ]</a> + <a href="author.html#16567">[ 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> |