[Steve Langasek, 23.03.2007] > 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.
My point is Python-Version can contain "current" in XB-P-V even if it's not in XS-P-V. It was just an proposal (for people that don't like redundant data) > > > > > 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'. when I write "current" I mean "single" (I didn't choose name for this keyword) If package is build for a single Python version and default Python version is not supported by this package, hashbang has to be set correctly and modules it provides (byte-)compiled (at build time *and* during the install/default python version change) > > 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. I couldn't set "python" in hashbang (as I said before: gaupol will not work with python2.3). Package was build when python2.3 was default so hashbang was set to python2.4. Now when python2.3 was removed from Debian, package needed binNMU (due to wrong hashbang) even if it's arch:all. > Oh, and if gaupol really needs python 2.4 or better, then the package's > current dependencies are wrong... python2.4 is default now so there's no need to add extra dependencies -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=-
pgphBsElVc2D9.pgp
Description: PGP signature
