Re: debian/pycompat usage?
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.
> > > > without offering any alternative
> > > > suitable for mass-detection of binNMU candidates.
> > > What if I provide you with a script that does the same without the
> > > fields?
> > So I get to unpack a couple hundred source packages on ftp-master/bugs.d.o
> > for each transition in order to inspect debian/pyversions in each one (and
> > who knows what else at this point) to identify the packages that are
> > binNMUable, instead of being able to get the same information out of
> > Packages+Sources? I don't find this plan particularly impressive.
> Given it has to be done about once or twice a year, I find it slightly
> better than asking a couple hundred maintainers to change their packages
> to add (among other things) fields with unclear definition and
> questionable usefulness.
I have never seen any discussion on this list about the problems with the
definitions of those fields; the questions of their utility likewise seems
to have only been raised in private. I think you have tried to kill off
these fields because you personally disapprove of using the control files in
this manner. Why else would you have gone ahead with the implementation
without ever raising the subject on this list so that people could try to
*resolve* the problems with these fields, or discuss alternate solutions
that would meet the needs of those wanting the fields, before dispensing
with them?
> With the net result of having several maintainers stepping back from
> maintaining python packages because they find it too complicated.
The only developer I know of who has stepped back from python maintenance in
Debian is Joe Wreschnig, who was quite explicit in expressing his
disapproval for a policy *process* that involved competing implementations
by maintainers who were not listening to each other, and behavior that was
changing from day to day in unstable. I have never heard anyone object that
any single proposal was too complicated.
--
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: