Le lundi 27 juin 2011 à 21:42 -0400, andre999 a écrit : > 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.
Then why do we replace foob by it in the first place if this break fooa ? > 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. The example is bogus. If we have fooa in the distro and we upload fooc that break it, then we have to fix the breakage as a priority. Usually, that would be having foob and fooc as parallel installablable. Anyway, the question is "how often does it" happens ? Because "it may happen" is not a justification" if in practice, it never happen. And not having a backport is not the end of the world so unless the problem is quite frequent ( and so far, this one is far from being frequent , especially since it is based on a wrong supposition in the first part ), I do not think this would be blocking. > >> 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.) Compatibility would be indeed a concern. But if we move packages between repository without rebuilding for QA reasons, this would also be meaningless. -- Michael Scherer