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é

Reply via email to