On Wed, Mar 21, 2007 at 04:50:30PM -0700, Steve Langasek wrote:
> On Thu, Mar 22, 2007 at 12:05:30AM +0100, Pierre Habouzit wrote:
> > On Wed, Mar 21, 2007 at 03:51:20PM -0700, Steve Langasek wrote:
> > > On Wed, Mar 21, 2007 at 11:16:14PM +0100, Pierre Habouzit wrote:
> > > > If we don't, I don't see the purpose of the policy alltogether.
>
> > > Allowing transitions between default versions of python without package
> > > renames, bypassing NEW, allowing binNMUable transitions, and generally
> > > simplifying the python upgrade path for users across releases.
>
> > > Supporting multiple binary extensions in a single python-foo package is a
> > > tool that *facilitates* that goal, but it was *never* supposed to be
> > > mandatory. There are extensions with no/few reverse-dependencies and a
> > > small install base, such that supporting multiple versions of python is
> > > useless archive bloat.
>
> > I see. What does "current" has to do with it then ? in the current
> > state of affairs, nothing prevent the maintainer to only build the
> > package for $(pyversions -d) only, which would be:
> > (1) binNMUable
> > (2) only built for the current python version as per spec of what you
> > want to achieve.
>
> 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.
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. As you already acknowledge the reverse situation also
holds.
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.
> 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.
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.
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.
> > Though, I know what you will argue next, it's that you need (as a RM)
> > to be able to compute the list of packages needing to be queued for
> > binNMU.
>
> Exactly. :)
>
> > I've not evaluated yet if current helps here or not (I don't think so, but
> > I've nothing to backup that assertion yet, so I wont say anything until
> > I've a good and minimal solution to propose).
>
> Ok, I look forward to hearing this proposal.
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).
* 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.
* 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".
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)
*phew*. I don't think I said anything new, I was just trying to sum up
my thoughts.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpzjL8wz0cmz.pgp
Description: PGP signature