Bug#190753: About dropping the ‘should’ recommendation to rename binary programs using a suffix to indicate their programming language.
On Mon, 05 Oct 2009, Charles Plessy wrote:
> As a user I strongly dislike to have to edit my scripts and command
> line sessions in order to make them usable for my colleagues, and I
> would be very annoyed if the first thing to do after installing a
> package would be to check if I have to change the PATH environment
> variable in my current sessions and my logins scripts.
The error here is upstream. Using language extensions in programs that
are part of a public API is wrong, and shouldn't be done. Fixing the
bug in Debian is only a partial solution. These bugs should also be
fixed upstream.
> But on the other hand, once this choice has been made and the
> program distributed, I think that the inconvenients of renaming only
> in Debian are higher than the advantages.
It shouldn't be renamed only in Debian. And even so, it's fairly
simple to work around in scripts even if upstream doesn't want to see
the light. "which" is your friend.
> Renaming is a practical disadvantage for the users and the package
> maintainers. What are the practical advantages?
The practical advantages are that 1) you can reimplement scripts
without renaming, 2) you don't make it more difficult on public users
of the binary who have to remember both the name and the entirely
arbitrary aspect of what language it was implemented in[1] and 3)
things are consistently named, no matter what the package is.
Furthermore, the policy is a *should* directive, not a *must*
directive. There are many cases where there are things that are done
wrongly, but fixing these historical mistakes are more costly than
living with them. A wontfix bug with possible lintian overrides may be
acceptable in such rare cases.
That said, most packages that are being added to Debian are relatively
new works, and don't have a huge historical userbase with legacy
scripts; fixing these sorts of issues upstream at the earliest
opportunity is the right way forward, and a should directive in policy
is the right way to inform everyone of what the proper practice is.
Don Armstrong
1: Obviously, tab completion works in interactive use, but it's
certainly not the case for writing scripts, documentation, or anything
else. If the code is only used interactively, then there's no real
downside to renaming it.
--
All bad precedents began as justifiable measures.
-- Gaius Julius Caesar in "The Conspiracy of Catiline" by Sallust
http://www.donarmstrong.com http://rzlab.ucr.edu
Reply to: