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
Reply to: