I'd suggest that, in cases where the name of a program is an interface[1],
and includes the implementation language, it would be reasonable, and
in the spirit of my original policy proposal, to ship a symlink that
does not include the implementation language in its name, and retain the
interface as necessary for compatability. It's reasonable to say a
package doing that still has a minor bug, but at least it's a minor bug
that does not inconvenience the user with suffixes.
If there are multiple programs in different languages, with the same
basename, then a symlink won't work; alternatives might, or not. But
surely such a confusing situation is itself a (non-minor) bug, and very
rare. Indeed, I can find no such cases in the archive. More commonly,
there is a program with a language extension that is a wrapper around a
binary without one (or in some cases, confusingly unrelated to the
binary without the extension). I count 20 such in the archive.
FWIW, I count[2] 158 programs in unstable with programming language
extensions, and the same number in stable. Oldstable had 194. Not much
progress but at least the number is not going up. If I could go back to
2003, I would have instead written a lintian check.
[1] Let's be careful here; the name of a program is not in all cases an
interface or API. If it were, any change to the name of a program
would be a bug, and that's clearly not so.
[2] zegrep '(^bin/|^sbin/|usr/bin/|usr/sbin/|usr/games/)' Contents-i386.gz|egrep -i '\.(php|py|pl|rb|hs|el|sh|tcl)'
--
see shy jo
Attachment:
signature.asc
Description: Digital signature