diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/006087.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/006087.html | 124 |
1 files changed, 124 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/006087.html b/zarb-ml/mageia-dev/2011-June/006087.html new file mode 100644 index 000000000..4154e2d62 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006087.html @@ -0,0 +1,124 @@ +<!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=%3C1309254414.31611.21.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="006074.html"> + <LINK REL="Next" HREF="006141.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=%3C1309254414.31611.21.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Backports policy proposal">misc at zarb.org + </A><BR> + <I>Tue Jun 28 11:46:53 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="006074.html">[Mageia-dev] Backports policy proposal +</A></li> + <LI>Next message: <A HREF="006141.html">[Mageia-dev] Backports policy proposal +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#6087">[ date ]</a> + <a href="thread.html#6087">[ thread ]</a> + <a href="subject.html#6087">[ subject ]</a> + <a href="author.html#6087">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le lundi 27 juin 2011 à 21:42 -0400, andre999 a écrit : +><i> Michael Scherer a écrit : +</I>><i> > +</I>><i> > Le vendredi 24 juin 2011 à 16:20 -0400, andre999 a écrit : +</I>><i> >> Michael Scherer a écrit : +</I>><i> +</I>><i> [...] +</I>><i> +</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>><i> +</I>><i> Suppose leaf package fooa depends on foob. foob is part of the current release. +</I>><i> Cauldron replaces foob with fooc. fooa is incompatible with fooc. +</I> +Then why do we replace foob by it in the first place if this break +fooa ? + +><i> fooa is requested by some users, and future versions of fooa are intended to be +</I>><i> compatible with fooc. +</I>><i> In this case, even though it wouldn't be testable in cauldron, it could be tested in +</I>><i> backports-testing, and I think it could be a good idea to allow it. +</I>><i> +</I>><i> Even if fooc compatibility wouldn't be available for the next Mageia release, a user +</I>><i> could avoid updating for a release in order to keep using fooa. +</I>><i> However, if there were no intention to make fooa compatible with fooc, maybe it should +</I>><i> be denied. +</I> +The example is bogus. If we have fooa in the distro and we upload fooc +that break it, then we have to fix the breakage as a priority. Usually, +that would be having foob and fooc as parallel installablable. + +Anyway, the question is "how often does it" happens ? Because "it may +happen" is not a justification" if in practice, it never happen. And not +having a backport is not the end of the world so unless the problem is +quite frequent ( and so far, this one is far from being frequent , +especially since it is based on a wrong supposition in the first part ), +I do not think this would be blocking. + +><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> +</I>><i> I would like to see the source repository info available for every installed package. +</I>><i> Maybe even stored somewhere in the .rpm file, also. +</I>><i> Is concerns for upstream compatibility for rpm or urpm* the a reason why we can't add +</I>><i> new fields to the packages database ? +</I>><i> (Although a parallel sqlite file would work.) +</I> +Compatibility would be indeed a concern. But if we move packages between +repository without rebuilding for QA reasons, this would also be +meaningless. +-- +Michael Scherer + +</PRE> + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="006074.html">[Mageia-dev] Backports policy proposal +</A></li> + <LI>Next message: <A HREF="006141.html">[Mageia-dev] Backports policy proposal +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#6087">[ date ]</a> + <a href="thread.html#6087">[ thread ]</a> + <a href="subject.html#6087">[ subject ]</a> + <a href="author.html#6087">[ 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> |