Le vendredi 24 juin 2011 à 16:20 -0400, andre999 a écrit : > Michael Scherer a écrit : > > > > so : > > - cannot be backported if this is not a leaf package, will be revised later > > - cannot be backported if the maintainer say "no", but we assume he say > > "yes" by default > > - cannot be backported if it impact the dependency tree too much ( > > Obsoletes, Provides, etc ) > > - 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. > > - 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. > > - strict requires between backported packages, in order to make sure they > > can be cherrypicked ( ie, someone enable backports, install, remove > > backports ) > > It would be best if one can select individual backports without activating > the backports > repositories, as is now the case. > So only the brave (wanting all backports) need activate the backports > repositories. > > Agree with everything, except as noted. > > It might be useful to list major packages that should never be backported. > 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. And tagging in the package name would be quite tricky to do if we need to play with %mkrel and release. -- Michael Scherer
