[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposed update to the python policy



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.
vorlon@debian.org                                   http://www.debian.org/



Reply to: