diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2012-June/016318.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2012-June/016318.html | 192 |
1 files changed, 192 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2012-June/016318.html b/zarb-ml/mageia-dev/2012-June/016318.html new file mode 100644 index 000000000..8c6be2316 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-June/016318.html @@ -0,0 +1,192 @@ +<!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=%3C4FD31FB9.6060807%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="016313.html"> + <LINK REL="Next" HREF="016416.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Backports policy clarification (and discussion)</H1> + <B>andre999</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=%3C4FD31FB9.6060807%40laposte.net%3E" + TITLE="[Mageia-dev] Backports policy clarification (and discussion)">andre999mga at laposte.net + </A><BR> + <I>Sat Jun 9 12:04:41 CEST 2012</I> + <P><UL> + <LI>Previous message: <A HREF="016313.html">[Mageia-dev] Backports policy clarification (and discussion) +</A></li> + <LI>Next message: <A HREF="016416.html">[Mageia-dev] Backports policy clarification (and discussion) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#16318">[ date ]</a> + <a href="thread.html#16318">[ thread ]</a> + <a href="subject.html#16318">[ subject ]</a> + <a href="author.html#16318">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>blind Pete a écrit : +><i> Samuel Verschelde wrote: +</I>><i> +</I>><i> +</I>>><i> Le vendredi 8 juin 2012 20:20:54, David W. Hodgins a écrit : +</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> wrote: +</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> In the upgrade from Mandriva 2010.2 to Mageia 1, it was made clear, that +</I>>>><i> upgrading from a system with 2010.2 Backports was not supported. It may +</I>>>><i> work, but was not recommended. +</I>>>><i> +</I>>>><i> I think we should keep the same policy for the upgrade from Mageia 1 to +</I>>>><i> 2. +</I>>>><i> I.E. Don't use backports if you are planning on later doing an upgrade, +</I>>>><i> 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> +Current tools will correctly update backports much of the time. (From +my experience.) +The tools just need to be reworked somewhat to ensure that backports are +updated correctly all of the time. + +>>><i> Regards, Dave Hodgins +</I>>>><i> +</I>>><i> Again, this is not the policy we adopted. When we defined the backports +</I>>><i> policy (together, although it seems most people are just discovering it +</I>>><i> now) we said that we didn't want to have backports that don't work, break +</I>>><i> a system, or prevent upgrade. +</I>>><i> +</I>>><i> However, I think that for DVD upgrade without internet access this is a +</I>>><i> sensible option. But the upgrader should detect the situation itself, not +</I>>><i> hope that the user will read somewhere in the release notes that it's not +</I>>><i> supported. +</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> +Cauldron's backport repos will always be empty. +If you introduce a new package, or a new version of an existing package +to Cauldron, it is not, by definition, a backport. Even though the same +version (not counting the revision) may be a backport for previous releases. + +So if we do a release update to the latest release, backports will be +replaced by regular packages except in those cases where a newer version +has been introduced into Cauldron. And if we update to Cauldron, all +backports will be replaced by regular packages -- according to our +backport policy. + +>><i> And there should be a way for those who have internet access to upgrade +</I>>><i> online *with* backports too. +</I>>><i> +</I> +True, to allow the user to do the release upgrade in one step. +>><i> Samuel +</I>>><i> +</I> +Effectively during release updates, we have to treat backports as +updates to installed backports. +Because dependancies may differ between releases for the backport, +installed backports will always have to be updated. +However many users are in a situation where they cannot do online +updates when installing a release update, (That is my situation.) So +they have to do updates as a separate step. +This means that in would be prudent to always treat backports as updates +to installed backports, even if not doing a release update. +If all backports packages are tagged as backports (in the file name), it +will be relatively easy for the tools to recognize and appropriately +treat backports. + +We have to avoid backports of packages that could make the system +unbootable, or the major desktops unstartable, but note that this is +already more than covered in the backport policy, under "packages scope". + +In sum, as long as our tools can clearly identify backports, it should +be easy to adapt them to properly treat backports. +So I think the policy should be changed to always tag backports in the +revision part of the file name to facilitate recognition of backports, +such as is usually done for "tainted" packages, and sometimes for "nonfree" + +Maybe to facilitate keeping backports up to date, we should ensure that +rpmdrake (and the other tools) include backports in the security and +bugfix options. This may already be the case. (While still treating +them as backports.) + +-- +André + +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="016313.html">[Mageia-dev] Backports policy clarification (and discussion) +</A></li> + <LI>Next message: <A HREF="016416.html">[Mageia-dev] Backports policy clarification (and discussion) +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#16318">[ date ]</a> + <a href="thread.html#16318">[ thread ]</a> + <a href="subject.html#16318">[ subject ]</a> + <a href="author.html#16318">[ 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> |