Re: Proposed update to the python policy
On Thu, Mar 22, 2007 at 01:17:17AM +0100, Pierre Habouzit wrote:
> > In the original proposal, 'current' was the flag to tell the packaging tools
> > that pyversions -d *should* be used. There is of course nothing that stops
> > a maintainer from invoking pyversions -d manually;
> Okay I see. As a coder, I don't like it then, and I feel reinforced in
> my gut dislike of that field. "current" is declarative, and does not
> says anything about what the packager really put in his debian/rules.
That's fine. I'm not wedded to the, ah, "current" implementation; my
concern is that it not be gutted from the policy because of concerns about
the implementation, instead of finding a non-buggy solution.
> If he does not writes what has to be to multi-build the package, and
> that he does not puts current, well, the package basically will only be
> built for current.
And in that case, do all of the helpers correctly calculate the Provides
based on the contents of the binary packages?
> And as a matter of a fact, maintainers do not seem to understand what
> current is for, Piotr python2.5-only package is a very good example of
> this IMHO.
Well, information surrounding 'current' is certainly muddled at present, but
I don't think that points to a technical flaw.
> > the question is, how will
> > doing so fit into the python policy, will there be support for automating
> > this in the helper tools, and will packages that do this (and are therefore
> > binNMUable for python transitions) be automatically detectable from the
> > Sources and/or Packages files?
> like I say later, I knew it was what really matters for you. And IMHO
> it's really more interesting that the dh_py* tools explains what has
> really been built. They already do the job to generate the correct
> substs for python:Depends and python:Provides, so basically, the code to
> detect that exists.
Yes, so automation of the package builds themselves is addressed, with or
without 'current'.
> One just has to make it clear in the Packages.gz files. Like I said, I
> don't really think Sources.gz are relevant, as it's declarative from the
> maintainer PoV.
I can't think of any reason it would be a problem to have this information
in Packages only.
> But like said, I've not yet thought about all the consequences yet,
> and I do not know what's needed or not. I've the suspicion that XB-P-V
> could indeed be the way to go (even if for packages with modules
> Provides: show that information already), but I'm not sure that the
> current use of XB-P-V carries all the information we need.
AIUI the current use of XB-P-V, as endorsed by the python policy, indicates
what versions of python the package has been built for, which is not all
that relevant for binNMUs; the same information can already be extracted
(though less easily) from the provides/depends. What is needed is a
description of what will happen to the package if a buildd is *attempted*
against a particular version of python.
> Thanks. I'll try to make this proposal driven from our needs, and not
> trying to advantage this or that implementation of the dh_py* helpers,
> which was the ground of the argument when I joined this (mess ?) half a
> year ago. I think with your explanations, I quite understand the
> requirements from the user and packager point of view (NEW, number of
> packages efficiency, etc...), and I believe the sole other need is the
> ease to deal with transitions from the RM PoV and for that it needs to
> answer the 3 questions:
> * what should be binNMUed for a python version removal (assuming it
> was not default btw ;P), that one is easy IMHO: basically nothing
> _needs_ to, but:
> + packages with a strong dependency on that pythonX.Y and _no_
> python dependency have to be dropped altogether (or likely need
> porting and are not binNMUable) ;
> + for space efficiency we could think of binNMUing every package
> that has built a public module for that particular python
> version. Here, XB-P-V is not needed if we have the Provides that
> is mandatory (and that is what Joss proposes, and I think it's
> sane anyway).
In addition to space efficiency, this should be done to ensure that packages
are in a consistent state at release time, so that we don't risk a security
update significantly changing the contents of one of these packages.
> * what should be done for a default python change: here concerned
> packages are:
> + packages with private binary extensions,
> + packages built only for the "current" python version.
Yes, I believe that's correct.
> * what should be done for a new python: here concerned packages are
> _only_ packages that build public binary modules for more than the
> "current" python. Here again, XB-P-V does not seems required if the
> Provides is, they provide the same information, except for the "I'm
> only built for current and if you binNMU me I won't generate a new
> package anyway".
Right.
> So that first quick look just says that what we need is a way to find
> out about packages that:
> * build private extensions (needed for question (2));
> * only build things for the default python version (opposed to those
> who build for as many as possible), knowing that I'm only speaking
> of packages with public binary modules here.
> (needed for 2, and for 3)
Looks right to me.
--
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: