Le lun 28 août 2006 08:33, Steve Langasek a écrit :
> On Sat, Aug 26, 2006 at 11:18:15AM +0200, Josselin Mouette wrote:
> > Le vendredi 25 août 2006 à 17:09 -0700, Steve Langasek a écrit :
> > > > As long as these fields don't even have clear semantics,
> > > > implementing them is, at best, useless.
> > >
> > > So, why has there been no discussion about the problems with the
> > > semantics and how they might be *fixed*?
> >
> > As they are fundamentally broken (especially by bringing things at
> > the package level when they should have stayed at the module
> > level), the best fix is to remove them instead of asking package
> > maintainers to change all their packages when it is not needed.
>
> The information I'm looking for is at the package level, not at the
> module level. Information about what versions of python a package is
> currently built for is at the binary level; information about what
> versions of python a package can be rebuilt for is at the source
> level. The latter could be defined as the intersection of what the
> individual modules in the package provide, which would work just fine
> for identifying binNMU candidates; I don't think the union would be
> useful, because I don't see it working very well to binNMU only
> *part* of a source package for a new version of python.
While working on the tool I promised I'll work on, I indeed agree that
the debian/pyversions beeing hidden is a major PITA. Note that it has
not been deprecated, it's just optional, and afaict, has always been
(at least since I work on that transition). So please on both (or any)
sides, calm a bit down.
That said, the very important and needed information of that field is
the upper bound[1] of the XS-P-V / pyversion, so I'll run on my local
mirror a script that will list every package that has one upper bound
and does not uses XS-P-V and either NMU the package (if the package was
NMUed for transition) or open a bug on the package to ask for the use
of XS-P-V in that case.
for any other case, we can suppose that it has no upper bound, and that
the binNMUs can be triggered smoothly.
For the rest, the XB-* fields are of no use as they are trivial to
interpret from the Depends line. You have to spot the python (>= X.Y),
python (<< Z.T) to know that the XB-P-V field contains all the
[X.Y, Z.T[ python versions. That is quite easy to to look at (at least
no harder than at the XS-P-V/XB-P-V field itself).
So my proposal is to make XS-P-V mandatory when there is an upper bound.
That could be a trivial lintian check, should provide you the necessary
information in a glance, while not needing too many packages to be
reuploaded because of that.
[1] obviously this is needed to know if a binNMU will make the package
support a new python or not, and avoid useless build time on the
buildds. The lower bound is less useful as we should almost never
donwgrade the default python, or reintroduce lower python versions.
so to me, the harm looks quite small, given the fact that my current
experiments show that only a few packages do have an upper bound,
and do not use XS-P-V already.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgp0ZW3B7hC8d.pgp
Description: PGP signature