Re: Bug#190753: About dropping the ‘should’ recommendation to rename binary programs using a suffix to indicate their programming language.
On Mon, Oct 05 2009, Russ Allbery wrote:
> Don Armstrong <don@debian.org> writes:
>
>> Changing policy without rough consensus would require a CTTE decision on
>> the matter. Since Russ and Manoj have both laid out their objections to
>> changing policy by removing the should directive, I don't believe there
>> is much hope in achieving rough consensus. [Honestly, since 3/3 of the
>> CTTE members who have commented on this[1] have made their opinion
>> fairly clear, I'm not sure if there's much hope in that path either.]
>
> For the record, while I supported the original Policy change and am
> leaning somewhat towards keeping it, I'm not firmly committed to that and
> could possibly have my mind changed. But I'm not really sure what line of
> reasoning would do it, or how best to decide.
>
> The strongest argument for changing Policy, IMO, is that the name of the
> binary is an interface and by changing the name of the binary, Debian is
> changing the interface in a way that invalidates upstream documentation
> and may require follow-on modifications to other programs. That's a big
> step to take, and I think there's a reasonable argument that this isn't a
> step we take necessarily in other places. We have libraries with bad ABIs
> that we haven't changed because while they're bad, they're not actively
> broken, and the compatibility is more important than fixing the design
> problems.
>
> Unfortunately, and I'm not sure on which side this argument falls, many of
> the upstream packages with this problem are generally a mess, and the
> language extensions aren't the only problem. Often the scripts have far
> too generic of names, are poorly written in other ways, or do completely
> bizarre things like the example that just showed up in debian-mentors of a
> Python program that imported another Python program in /usr/bin as a
> module.
If we believe that the upstream API is wrong, it would generally
still be a good thing to fix it for our users and downstream, this
falls under improving the software we include in our OS, and in being a
good citizen in the free software community (as opposed to just
glorified packagers). The cut off point is the amount of pain it takes
to cascade the changes down the dependent packages; if the dependency
tree is shallow, I think doing the right thing would override minor
conveniences (especially since renaming a script in debian/rules is
trivial).
If it can be show that a significant number of unrelated
packages are dependent on the naming, ans we shall have to
cascade the changes to these other packages, then we might want an
exception. But so far, I have not seen much evidence of any significant
number of unrelated packages that would be so impacted.
Thus, I would be in favour of keeping the should rule as it is.
manoj
--
"Be there. Aloha." Steve McGarret, _Hawaii Five-Oh_
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: