Bug#190753: About dropping the ‘should’ recommendation to rename binary programs using a suffix to indicate their programming language.
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 scripts are installed into the system PATH, then it's because people
> who install those packages are expected to be able to make use of them
> as a public API, and they should generally be treated as such.
I think this argument cuts both ways: the public API should not hard-code
the implementation language, and Debian in general shouldn't change the
public API because it creates a lot of work for us and our users. I'm not
sure which direction cuts deeper.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: