On Fri, Mar 23, 2007 at 10:39:45AM +0100, Piotr Ożarowski wrote:
> [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)
current in X?-P-V sucks a lot because X?-P-V explains which python
version the package supports, whereas current is not about that but
about the kind of packaging ways it has. This information should never
have been folded in the same field, I only recently got what it really
meant because of that. It's more than confusing.
> > 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)
IMHO that's better suited to say that to the dh_tool. Like a :
dh_py{support,central} --single-version
That would indeed flag the package in the Packages accordingly (but
XB-P-V is not the place IMHO).
But yes, this information really has to "leak" somehow as the RM needs
it.
As of your python-dev (>> 2.5) | python2.5-dev be warned that it does
not works for an arch:any package: sbuild always take the first
alternative, so an arch:any package won't build with that hack. It only
works for arch:all packages as pbuilder/debuild/...whatever are more
clever about that.
So there is no way to deal with packages that only support "future"
python versions yet. Though I expect it to concern only a few packages
that will need a sourcefull upload to migrate to a scheme where they
support the policy.
Your B-D + XS-P-V hack only works with brittle side effects, and for
arch:all packages, that are not subject to binNMUs anyway (at least not
untill we have arch:all buildd's).
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgprSmMvvHPg9.pgp
Description: PGP signature