On Fri, Mar 23, 2007 at 09:58:18AM +0100, Piotr Ożarowski wrote: > > - relying on Build-Depends to indicate whether a package builds "current" or > > "all" doesn't seem to leave a way to differentiate between packages that > > follow the new policy and really /are/ binNMUable, from those that don't > > follow the new policy but obviously still need to b-d on python-*dev. > > - Build-Depends information is only in the Sources file, not in Packages; > > detecting packages that need binNMUs requires trawling the Packages file, > > it would be nice if it didn't require correlating both Packages and > > Sources
> Build-Depends is used only at build time. Python-Versions field is in binary > package. Sorry, what's your point? You seem to be repeating what I've said. > > > > As I understood it, "current" indicates that the package should only be > > > > built for one version of python, the version that is currently the > > > > default version in Debian. > > > not necessary default (see "current, >=2.X" where 2.X is greater than > > > default) > > > but for single version only, yes. I understand it this way, but > > > apparently I don't understand "current", though. > > I don't think it was intended that "current, >= 2.X" be used to > > *successfully* build packages when 2.X is greater than the currently > > available python-dev. > if python-dev (>=2.X) | python2.X-dev is not available during build > process, it will just fail and maintainer will not be able to upload > such package, am I right? Ugh, it should fail *regardless* of the existence of python2.X-dev. Why would you ever call it "current" if it's building for something that *isn't* the current version of python? A package should only be called "python-foo" if it's built for "python"; if it's built for python2.X explicitly, the package name needs to reflect that, which means manual changes are needed to update it for a new python version. That's out of scope for 'current'. > BTW: "current, >=2.4" helped me a lot with packaging gaupol when > python2.3 was default Which is not an arch: any package, so is irrelevant to binNMU support. Oh, and if gaupol really needs python 2.4 or better, then the package's current dependencies are wrong... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
