[Mageia-dev] Backports policy proposal

[andre999]

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é