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.)
- 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.)
- 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. (I'd like the database to retain all the source repositories of installed packages.) -- André
