Re: debian/pycompat usage?
On Tue, Sep 05, 2006 at 07:14:18PM +0200, Josselin Mouette wrote: Le mardi 05 septembre 2006 à 16:54 +0200, Andreas Barth a écrit : Well, the main objector was present in Mexico in the BOF, but started a bad campaing after being back from Mexico. That was not helpfull at all. Remember. I already expressed concerns during the BoF itself. Then, it turned out later that the fields had unclear specifications and could only be used by python-central itself. There is at least a lesson to retain: the BoF itself was a bad idea from the beginning. I hope people won't make again the mistake to define policies in a meeting. I think the only lesson is to not invite you to such meetings, because you'll piss on any attempt at building consensus anyway. -- 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]
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. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian/pycompat usage?
Le lun 28 août 2006 09:12, Pierre Habouzit a écrit : 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. the list of suck packages (run on a fresh local miror) is: avahi : 2.4 bzrtools: 2.4 codeville : 2.3 drpython: 2.3 gaphor : 2.4 gnome-sudoku: 2.4 hamlib : 2.3-2.5 libmetakit2.4.9.3 : 2.3 opensync: 2.4 and I suspect that most of those should have been x.y- and not x.y. the 2.3-2.5 from hamlib looks quite suspicious. and those two are buggy: notify-python : =2.3 - should be 2.3- xulrunner : current - should be 2.3- as well I will fill reports to ask the pyversions fields to be sort out, but please be reassured wrt that transition, the lack of XS-P-V is (by luck I reckon) not harmfull yet, and I'll personnaly ensure that it won't become. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpsMNPvRtKrR.pgp Description: PGP signature
Re: debian/pycompat usage?
Le samedi 26 août 2006 à 16:12 +0200, Floris Bruynooghe a écrit : You'll never need to update a package for just modifying the P-V fields. Why use the future tense? This has already happened. Dozens of packages were NMUed to add these fields while this was not necessary. Most of these packages could have been just rebuilt with an improved dh_python. But it looked so much easier to change all these packages so that their maintainers don't even understand what they should do. Just wonder why, after that, people discuss of stupid ways to follow the release schedule. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: debian/pycompat usage?
Le dimanche 27 août 2006 à 23:33 -0700, Steve Langasek a écrit : 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. Indeed. This is why these fields are inappropriate, because they concern the module level, despite being stored in the package metadata. I have never seen any discussion on this list about the problems with the definitions of those fields; Manoj raised these problems better than I would. 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? Because not only do I dislike this use of control files, but I also dislike this discuss policy first, code after way of doing things. One of the reasons for the python fiasco is that the crappy document that was called new policy was written into stone before having even been tried on a few packages. The best way to prove it was to write a better implementation. 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. This is the general impression I get from reading this list (people asking for NMUs for changes that should have been trivial), private discussion with maintainers, and bug reports. This transition may have uncovered some packages that were already unmaintained, but it has also discouraged some maintainers who thought they needed more time to understand the new policy. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: debian/pycompat usage?
On Mon, Aug 28, 2006 at 09:53:20AM +0200, Josselin Mouette wrote: Le dimanche 27 août 2006 à 23:33 -0700, Steve Langasek a écrit : 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? Because not only do I dislike this use of control files, but I also dislike this discuss policy first, code after way of doing things. One of the reasons for the python fiasco is that the crappy document that was called new policy was written into stone before having even been tried on a few packages. The best way to prove it was to write a better implementation. Fair point. The entire new policy and transition where way too hurried to start with which doesn't work when not everyone agrees. But maybe there's a lesson about this for the future. I can agree with your reasoning of trying out implementations, but it seems to me something to be done in experimental so that only packages who want to try it do so. The python-central package should have stayed in experimental during that time too obviously so that only when the new policy was agreed upon the helpers who comply with it are uploaded into unstable. But again, the tight timeframe made this complicated. Secondly it should be noted that communication didn't go too good either since people in favour of the P-V fields didn't realise not everyone was happy with it and thought it was fine to go ahead with introducing it to unstable. It also took ages before the list was informed of what did happen during the BOF (not having the video's right away didn't help) which made matters even more obscure. But it's a fair point to say that the transition first, new policy later principle should not have been changed as it is now seen that a new policy takes time, more time then there was for the transition. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian/pycompat usage?
Le lundi 28 août 2006 à 09:12 +0200, Pierre Habouzit a écrit : While working on the tool I promised I'll work on, I indeed agree that the debian/pyversions beeing hidden is a major PITA. I'm afraid that looking for this information in debian/pyversions is not going to give any better results than looking in the control fields. As you already explained, the Depends: line already contains most of the information. Another thing to look is for .so files corresponding to several python versions in /usr/lib/python-support/*/python2.? or /usr/lib/python2.?/site-packages. So my proposal is to make XS-P-V mandatory when there is an upper bound. Beware of one thing: having both XS-P-V and pyversions is the worst case we can have, as the maintainer has to ensure they contain the same information. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: debian/pycompat usage?
On Mon, Aug 28, 2006 at 09:53:20AM +0200, Josselin Mouette wrote: Le dimanche 27 août 2006 à 23:33 -0700, Steve Langasek a écrit : changing from day to day in unstable. I have never heard anyone object that any single proposal was too complicated. This is the general impression I get from reading this list (people asking for NMUs for changes that should have been trivial), private discussion with maintainers, and bug reports. This transition may have uncovered some packages that were already unmaintained, but it has also discouraged some maintainers who thought they needed more time to understand the new policy. Speaking as someone who ended up asking for help I found that the problem wasn't understanding the policy itself but rather with understanding how to implement it. When I came to do the transition I spent quite a bit of time trying to work out on what basis to choose between the two different ways of supporting the new policy with debhelper since there is so little difference between the two from the user point of view but noticable differences in the end results. Had there been agreement on the implementation side I wouldn't have been so confused - I spent most of my time assuming that I must be missing something. -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: debian/pycompat usage?
Le vendredi 25 août 2006 à 17:09 -0700, Steve Langasek a écrit : This decision was not unilateral, sorry. It was a decision, made by you as python-support maintainer, in direct contradiction to what Matthias and I had discussed before DebConf and the conclusions of the DebConf python BoF, without any consideration given to the original goal of these fields. That's unilateral. If unilateral means that some people were disagreeing, you could also say the decision to implement them at first was unilateral. 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. 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. With the net result of having several maintainers stepping back from maintaining python packages because they find it too complicated. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: debian/pycompat usage?
* Josselin Mouette [EMAIL PROTECTED] [2006-08-26 11:18:15 +0200]: Le vendredi 25 août 2006 à 17:09 -0700, Steve Langasek a écrit : This decision was not unilateral, sorry. It was a decision, made by you as python-support maintainer, in direct contradiction to what Matthias and I had discussed before DebConf and the conclusions of the DebConf python BoF, without any consideration given to the original goal of these fields. That's unilateral. If unilateral means that some people were disagreeing, you could also say the decision to implement them at first was unilateral. unilateral adj 1: involving only one part or side -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature
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), (I'm reading this without the especially word as I think that's what's intended) It could be argued that this information is important at package level. It gives valuable information about the package during a transition by telling what needs to happen to the package. Also the point of the new policy was to make transitions easier, having to unpack all modules is counter productive in that matter. This makes it a lot harder for individual people to investigate the state of packages (during a transition) too, which is not so good IMHO. If this is inexpensive it could be done multiple times during a transition which might be convenient sometimes. Lastly there are (AFAIK) no negative effects from adding the X-fields to dpkg's database. So I don't see why the inconvenience of having to unpack all packages to inspect them during transitions outweighs the (mostly?) harmless P-V fields. the best fix is to remove them instead of asking package maintainers to change all their packages when it is not needed. You'll never need to update a package for just modifying the P-V fields. When a new policy is created all packages need to be updated anyway. It is worth noting that old transitions also needed manual intervention. Hence in the long run this is one extra thing to do when updating it now but will safe work later. I mean debian/pyversion needs to be created too, requiring maintainers to change all their packages. 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. With the net result of having several maintainers stepping back from maintaining python packages because they find it too complicated. The net result is not actually very complicated. I was under the impression some maintainers stepped back because of all the confusion and unclearness created by having 2 different opinions being pressed through. I must say that currently it's quite hard to figure out what The Right Way is to make a python package that conforms with policy. And I might even say that it's plain guesswork to try and make a package that will conform to policy *in the future* ;-P Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian/pycompat usage?
Hi,
On Fri, 25 Aug 2006, Floris Bruynooghe wrote:
AIUI debian/pycompat is not needed anymore currently as dh_python has
enough by having the XS-Python-Version field, while if you are using
python-support dh_python is not used at all anymore so it doesn't need
the debian/pycompat anymore either.
Please correct me if I'm wrong. Also the wiki needs updating to
reflect this, so if no one corrects me I will do that (unless someone
beats me to it).
You're right. However there's no point in changing that now, until we have
a proper plan to get rid of dh_python completely and replacing it with
another common infrastructure to generate the ${python:*} substitutions.
I tried to propose one but Matthias Klose didn't respond at all and
Josselin Mouette hasn't given his approval for such a common
infrastructure (even if he agreed on the principle the day when he agreed
to keep dh_python as common thing).
See: http://lists.debian.org/debian-python/2006/08/msg00091.html
Also, fairly unrelated, since pyversions is part of the python package
should we build-depend on python? I found somewhere that
build-depending on python-all-dev (= 2.3.5-11) is sufficient to pull
in pyversions, is that really the appropriate way though? I would
prefer to list python directly as dependency instead of indirect.
If you really need python-all-dev, then it's enough, indeed. If you still
want to list explicitely it doesn't hurt.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian/pycompat usage?
Le ven 25 août 2006 03:50, Floris Bruynooghe a écrit : Hello I've somewhat lost track of the exact current status of the new policy. AIUI debian/pycompat is not needed anymore currently as dh_python has enough by having the XS-Python-Version field, while if you are using python-support dh_python is not used at all anymore so it doesn't need the debian/pycompat anymore either. Please correct me if I'm wrong. Also the wiki needs updating to reflect this, so if no one corrects me I will do that (unless someone beats me to it). debian/pycompat is needed if you want dh_python to do the substitution. You also can (atm) use dh_pysupport do it alone, in that case you must not use debian/pycompat, neither dh_python. Also, fairly unrelated, since pyversions is part of the python package should we build-depend on python? I found somewhere that build-depending on python-all-dev (= 2.3.5-11) is sufficient to pull in pyversions, is that really the appropriate way though? I would prefer to list python directly as dependency instead of indirect. it depends. if you build for a pythonX.Y you should just B-D on pythonX.Y-dev, if you build for current on python-dev, if you do a multi-build you should use python-all-dev. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp6dhSCgeDIt.pgp Description: PGP signature
Re: debian/pycompat usage?
On Fri, 25 Aug 2006, Pierre Habouzit wrote: debian/pycompat is needed if you want dh_python to do the substitution. You also can (atm) use dh_pysupport do it alone, in that case you must not use debian/pycompat, neither dh_python. If someone really wants to use dh_pysupport to generate the dependencies, it would be better with an expliciti -d option instead of relying on the absence of a file. The interface is clearer for everybody until we have again decided the proper way of handling everything without dh_python. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian/pycompat usage?
Le vendredi 25 août 2006 à 09:41 +0200, Raphael Hertzog a écrit :
Hi,
On Fri, 25 Aug 2006, Floris Bruynooghe wrote:
AIUI debian/pycompat is not needed anymore currently as dh_python has
enough by having the XS-Python-Version field, while if you are using
python-support dh_python is not used at all anymore so it doesn't need
the debian/pycompat anymore either.
Please correct me if I'm wrong. Also the wiki needs updating to
reflect this, so if no one corrects me I will do that (unless someone
beats me to it).
You're right. However there's no point in changing that now, until we have
a proper plan to get rid of dh_python completely and replacing it with
another common infrastructure to generate the ${python:*} substitutions.
I tried to propose one but Matthias Klose didn't respond at all and
Josselin Mouette hasn't given his approval for such a common
infrastructure (even if he agreed on the principle the day when he agreed
to keep dh_python as common thing).
I will not use the common infrastructure until it gets seriously fixed.
-rwxr-xr-x 1 root root 11709 2006-08-10 13:30 /usr/bin/dh_pysupport
-rwxr-xr-x 1 root root 24020 2006-07-10 14:14 /usr/bin/dh_python
This means twice as much code without handling all cases dh_pysupport
currently handles (including compatibility with the old dh_python).
Currently, with a relatively small amount of work, we could completely
replace dh_python with dh_pysupport without breaking compatibility for
older packages, and I believe this would be the sanest approach. However
Joey Hess doesn't want this to happen as long as python-central exists,
and I fear that Matthias Klose will refuse anything that would bring us
out of this horrible new policy mess (despite the proof that 80% of
this policy thing is nothing but useless complication for package
maintainers).
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: debian/pycompat usage?
On Fri, Aug 25, 2006 at 02:43:29PM +0200, Josselin Mouette wrote:
Le vendredi 25 août 2006 à 09:41 +0200, Raphael Hertzog a écrit :
On Fri, 25 Aug 2006, Floris Bruynooghe wrote:
AIUI debian/pycompat is not needed anymore currently as dh_python has
enough by having the XS-Python-Version field, while if you are using
python-support dh_python is not used at all anymore so it doesn't need
the debian/pycompat anymore either.
Please correct me if I'm wrong. Also the wiki needs updating to
reflect this, so if no one corrects me I will do that (unless someone
beats me to it).
You're right. However there's no point in changing that now, until we have
a proper plan to get rid of dh_python completely and replacing it with
another common infrastructure to generate the ${python:*} substitutions.
I tried to propose one but Matthias Klose didn't respond at all and
Josselin Mouette hasn't given his approval for such a common
infrastructure (even if he agreed on the principle the day when he agreed
to keep dh_python as common thing).
I will not use the common infrastructure until it gets seriously fixed.
-rwxr-xr-x 1 root root 11709 2006-08-10 13:30 /usr/bin/dh_pysupport
-rwxr-xr-x 1 root root 24020 2006-07-10 14:14 /usr/bin/dh_python
This means twice as much code without handling all cases dh_pysupport
currently handles (including compatibility with the old dh_python).
Currently, with a relatively small amount of work, we could completely
replace dh_python with dh_pysupport without breaking compatibility for
older packages, and I believe this would be the sanest approach. However
Joey Hess doesn't want this to happen as long as python-central exists,
and I fear that Matthias Klose will refuse anything that would bring us
out of this horrible new policy mess (despite the proof that 80% of
this policy thing is nothing but useless complication for package
maintainers).
I object to basing future work exclusively on dh_pysupport as long as it
implements your unilateral decision to abandon the XB-Python-Version field
and deprecate the XS-Python-Version without offering any alternative
suitable for mass-detection of binNMU candidates.
--
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]
Re: debian/pycompat usage?
Le sam 26 août 2006 00:39, Pierre Habouzit a écrit : Le ven 25 août 2006 22:26, Josselin Mouette a écrit : Le vendredi 25 août 2006 à 13:09 -0700, Steve Langasek a écrit : I object to basing future work exclusively on dh_pysupport as long as it implements your unilateral decision to abandon the XB-Python-Version field and deprecate the XS-Python-Version This decision was not unilateral, sorry. As long as these fields don't even have clear semantics, implementing them is, at best, useless. 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? I will do that, I've promised it. I've had a hell of a week, but I will work on that this week. week-end obviously sorry. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpXopAAE8GvB.pgp Description: PGP signature
Re: debian/pycompat usage?
On Fri, Aug 25, 2006 at 10:26:54PM +0200, Josselin Mouette wrote: Le vendredi 25 août 2006 à 13:09 -0700, Steve Langasek a écrit : I object to basing future work exclusively on dh_pysupport as long as it implements your unilateral decision to abandon the XB-Python-Version field and deprecate the XS-Python-Version This decision was not unilateral, sorry. It was a decision, made by you as python-support maintainer, in direct contradiction to what Matthias and I had discussed before DebConf and the conclusions of the DebConf python BoF, without any consideration given to the original goal of these fields. That's unilateral. 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*? 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. -- 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/ signature.asc Description: Digital signature
