diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/006074.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/006074.html | 136 |
1 files changed, 136 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/006074.html b/zarb-ml/mageia-dev/2011-June/006074.html new file mode 100644 index 000000000..4d7726bdf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006074.html @@ -0,0 +1,136 @@ +<!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=%3C4E093198.8060009%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="006020.html"> + <LINK REL="Next" HREF="006087.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Backports policy proposal</H1> + <B>andre999</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Backports%20policy%20proposal&In-Reply-To=%3C4E093198.8060009%40laposte.net%3E" + TITLE="[Mageia-dev] Backports policy proposal">andr55 at laposte.net + </A><BR> + <I>Tue Jun 28 03:42:48 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="006020.html">[Mageia-dev] Backports policy proposal +</A></li> + <LI>Next message: <A HREF="006087.html">[Mageia-dev] Backports policy proposal +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#6074">[ date ]</a> + <a href="thread.html#6074">[ thread ]</a> + <a href="subject.html#6074">[ subject ]</a> + <a href="author.html#6074">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Michael Scherer a écrit : +><i> +</I>><i> Le vendredi 24 juin 2011 à 16:20 -0400, andre999 a écrit : +</I>>><i> Michael Scherer a écrit : +</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>><i> +</I>><i> Give a more precise example. +</I> +Suppose leaf package fooa depends on foob. foob is part of the current release. +Cauldron replaces foob with fooc. fooa is incompatible with fooc. +fooa is requested by some users, and future versions of fooa are intended to be +compatible with fooc. +In this case, even though it wouldn't be testable in cauldron, it could be tested in +backports-testing, and I think it could be a good idea to allow it. +Even if fooc compatibility wouldn't be available for the next Mageia release, a user +could avoid updating for a release in order to keep using fooa. +However, if there were no intention to make fooa compatible with fooc, maybe it should +be denied. + +>>><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>><i> +</I>><i> If we decide to use the spec from cauldron on stable ( as it seems to be +</I>><i> the sanest way of doing it ), the only way to have a newer version in +</I>><i> stable than in cauldron would be to have the build broken on cauldron. +</I>><i> +</I>><i> If we tolerate this, and if no one fix ( because the person that did the +</I>><i> upgrade only care about stable release ), we have a broken build. +</I>><i> +</I>><i> So forcing the build to be correct on cauldron would be a stronger +</I>><i> incentive to fix. It seems more desirable to prevent a backport if the +</I>><i> price to pay is to have a potentially broken cauldron package. +</I> +Good point. Possibly a little more work for the moment, for greater stability. +But the example in the previous case above gives an exception -- which might be +reasonable to allow. + +[...] + +>><i> I like the idea of tagging backports in the package name, as well as in the package database. +</I>><i> +</I>><i> We cannot tag in the packages database. Yum do it with a separate sqlite +</I>><i> file, afaik. +</I> +I would like to see the source repository info available for every installed package. +Maybe even stored somewhere in the .rpm file, also. +Is concerns for upstream compatibility for rpm or urpm* the a reason why we can't add +new fields to the packages database ? +(Although a parallel sqlite file would work.) + +><i> And tagging in the package name would be quite tricky to do if we need +</I>><i> to play with %mkrel and release. +</I> +Right. I thought about this afterwards. + + +-- +André +</PRE> + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="006020.html">[Mageia-dev] Backports policy proposal +</A></li> + <LI>Next message: <A HREF="006087.html">[Mageia-dev] Backports policy proposal +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#6074">[ date ]</a> + <a href="thread.html#6074">[ thread ]</a> + <a href="subject.html#6074">[ subject ]</a> + <a href="author.html#6074">[ 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> |