[Mageia-dev] Backports policy proposal

Tue Jun 28 11:46:53 CEST 2011

Le lundi 27 juin 2011 à 21:42 -0400, andre999 a écrit :
+> Michael Scherer a écrit :
+> >
+> > Le vendredi 24 juin 2011 à 16:20 -0400, andre999 a écrit :
+> >> Michael Scherer a écrit :
+> 
+> [...]
+> 
+> >>> - cannot be backported if the package was just created and is thus basically untested in cauldron
+> >>
+> >> What about corner cases where a potential backport is incompatible with changes introduced in
+> >> cauldron ?  Should we leave such packages to third parties ?  (I would tend to say yes.)
+> >
+> > Give a more precise example.
+> 
+> Suppose leaf package fooa depends on foob.  foob is part of the current release.
+> Cauldron replaces foob with fooc.  fooa is incompatible with fooc.
+
+Then why do we replace foob by it in the first place if this break
+fooa ?
+
+> 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.
+
+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 like the idea of tagging backports in the package name, as well as in the package database.
+> >
+> > We cannot tag in the packages database. Yum do it with a separate sqlite
+> > file, afaik.
+> 
+> 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.)
+
+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
+
+