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. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]