diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/006020.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/006020.html | 139 |
1 files changed, 139 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/006020.html b/zarb-ml/mageia-dev/2011-June/006020.html new file mode 100644 index 000000000..48d86b123 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006020.html @@ -0,0 +1,139 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Backports policy proposal + </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%20proposal&In-Reply-To=%3C1309041705.22020.233.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="005999.html"> + <LINK REL="Next" HREF="006074.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Backports policy proposal</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Backports%20policy%20proposal&In-Reply-To=%3C1309041705.22020.233.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Backports policy proposal">misc at zarb.org + </A><BR> + <I>Sun Jun 26 00:41:44 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="005999.html">[Mageia-dev] Backports policy proposal +</A></li> + <LI>Next message: <A HREF="006074.html">[Mageia-dev] Backports policy proposal +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#6020">[ date ]</a> + <a href="thread.html#6020">[ thread ]</a> + <a href="subject.html#6020">[ subject ]</a> + <a href="author.html#6020">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le vendredi 24 juin 2011 à 16:20 -0400, andre999 a écrit : +><i> Michael Scherer a écrit : +</I>><i> > +</I>><i> > so : +</I>><i> > - cannot be backported if this is not a leaf package, will be revised later +</I>><i> > - cannot be backported if the maintainer say "no", but we assume he say "yes" by default +</I>><i> > - cannot be backported if it impact the dependency tree too much ( Obsoletes, Provides, etc ) +</I>><i> > - cannot be backported if the package was just created and is thus basically untested in cauldron +</I>><i> +</I>><i> What about corner cases where a potential backport is incompatible with changes introduced in +</I>><i> cauldron ? Should we leave such packages to third parties ? (I would tend to say yes.) +</I> +Give a more precise example. + +><i> > - must not prevent upgrade to next release +</I>><i> +</I>><i> I can see where a backport could be a more recent version than in cauldron for the moment. Since +</I>><i> that could make the newer version available to users somewhat sooner. Although by release, +</I>><i> cauldron should have at least as recent a version. Or should we prohibit this ? +</I>><i> (I'm thinking of cases where more recent versions are expected for cauldron before release.) +</I> +If we decide to use the spec from cauldron on stable ( as it seems to be +the sanest way of doing it ), the only way to have a newer version in +stable than in cauldron would be to have the build broken on cauldron. + +If we tolerate this, and if no one fix ( because the person that did the +upgrade only care about stable release ), we have a broken build. + +So forcing the build to be correct on cauldron would be a stronger +incentive to fix. It seems more desirable to prevent a backport if the +price to pay is to have a potentially broken cauldron package. + + +><i> > - strict requires between backported packages, in order to make sure they can be cherrypicked ( ie, someone enable backports, install, remove backports ) +</I>><i> +</I>><i> It would be best if one can select individual backports without activating the backports +</I>><i> repositories, as is now the case. +</I>><i> So only the brave (wanting all backports) need activate the backports repositories. +</I>><i> +</I>><i> Agree with everything, except as noted. +</I>><i> +</I>><i> It might be useful to list major packages that should never be backported. +</I>><i> I like the idea of tagging backports in the package name, as well as in the package database. +</I> +We cannot tag in the packages database. Yum do it with a separate sqlite +file, afaik. + +And tagging in the package name would be quite tricky to do if we need +to play with %mkrel and release. + + +-- +Michael Scherer + +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="005999.html">[Mageia-dev] Backports policy proposal +</A></li> + <LI>Next message: <A HREF="006074.html">[Mageia-dev] Backports policy proposal +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#6020">[ date ]</a> + <a href="thread.html#6020">[ thread ]</a> + <a href="subject.html#6020">[ subject ]</a> + <a href="author.html#6020">[ 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> |