[Mageia-dev] Backports policy proposal

Tue Jun 28 03:42:48 CEST 2011

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.
+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.
+
+>>> - must not prevent upgrade to next release
+>>
+>> I can see where a backport could be a more recent version than in cauldron for the moment.  Since
+>> that could make the newer version available to users somewhat sooner.  Although by release,
+>> cauldron should have at least as recent a version.  Or should we prohibit this ?
+>> (I'm thinking of cases where more recent versions are expected for cauldron before release.)
+>
+> 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.
+
+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 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.)
+
+> And tagging in the package name would be quite tricky to do if we need
+> to play with %mkrel and release.
+
+Right.  I thought about this afterwards.
+
+
+-- 
+André
+