Hi, Am Dienstag, den 09.08.2011, 11:33 +0200 schrieb Philipp Kern: > > > > easy linux-latest-2.6/39 linux-2.6/3.0.0-1 linux-kbuild-2.6/3.0.0-2 > > > This one is correct. > > > So I think britney's rule that blocks out-of-date binaries to appear in testing > > > should be implemented in sat-britney. It should be configurable to allow (libs > > > oldlibs) in, though. Would that be possible? > > > > Probably. Can you give an exact definition of that requirements: „A > > source package may not be in testing if...“ > > > > Bonus points if the definition can be verified with regard to the > > current _state_ of testing and unstable, without talking about changes. > > A package that gets into testing should have the same set of binary packages as > unstable, unless the additional binaries are in section libs or oldlibs[1]. A > naive thought would be "if this package would be in testing => binaries foo and > bar, that are no longer built in unstable, cannot be in testing too". I’m still trying to wrap my head around the problem to come up with a precise formal definition, given a two set of binary packages (triples name/version/arch, one for unstable, one for testing) an a function (or right-unique, left-total relation) “builtBy” mapping binary packages to source packages (tuple name/version). Things get more complicated because „does no longer build in unstable“ ist not a simple observation but rather an analysis such as „Take the name of the source of the package. Look for the newest version of a source package of that name. See if there are any binaries built from that source on the current architecture. Check if any of them have the same name.“ But maybe this is not required, old versions of packages of the same name cannot exist in testing (one-binary-per-arch requirement). Also, we are looking for a constraint, e.g. a statement about what may not happen. If b2 now accepts hints for packages from libs/oldlibs, maybe the number of false positive from SAT-Britney will drop anyways, given that with other sections, it is rare to rename one binary while other packages still depend on the old name. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: This is a digitally signed message part