Proposal: stop removing language extensions from script names

Currently, the Policy's section 10.4 contains:

In the Policy, should has the following meaning (sect. 1.1):

As a consequence, programs with names such as are actively renamed foo in many Debian packages. One of the main consequences of this policy is that a script developed on Debian and calling these programs will not run on other platforms such as Fedora, CenOS, Mac OS, etc.

This proposal is to relax the Policy by stopping to ask to rename the scripts, in order to restore portability between Debian and other systems.

Pros and cons

Reasons for not renaming scripts in Debian

Renaming programs create incompatibilities with systems where they were not renamed. Most major Free and non-Free platforms (Fedora, CentOS, Mac OS X, etc.) do not have Debian's policy of renaming programs. Therefore, a script developed on Debian will not run on these programs and vice-versa.

This breakage comes as a surprise to non-Debian users, who are mostly unaware of our policy, but also to Debian users, who are not all aware either.

The breakage does not affect only scripts, but also documentation, which is either not systematically corrected, or not correctable (on-line tutorials, books, etc.). Regression tests may also break, or fail to test the renamed scripts when they call the programs from the build directory directly instead of the PATH.

Removing language name extensions increase the probability of namespace collisions.

For the users who want to ensure compatibility with other platforms, discovering which program has been renamed is time-consuming and error prone.

For the maintainers of packages applying the policy, the renaming gymnastic is taking extra time, and opens the possibility of introducing new bugs (for instance when there are a foo and a program in the same package.

Reasons for renaming scripts in Debian

Users should not care what the implementation language is.

It looks unprofessional and flies in the face of unix tradition.

It's harder to type.

If Upstream rewrites the script in a different programming language and does not implement a migration strategy, Debian users will benefit from the stability of the script name (for instance, becomes, but in Debian the name foo is used constantly). Alternative benefit: the package maintianer does not have to implement a migration strategy for Debian a posteriori.

Language name extensions are not needed in Debian to execute a script with the correct interpreter.

Using language extensions is fundamentally wrong. Requiring good practice on the part of our upstreams is part of the "price" of being distributed as part of Debian.

Reasons for not recommending upstream to distribute scripts without extension names

If they want to support Windows, they need to include an extension in the file name.

Reasons for not recommending upstream to distribute scripts without extension names

Rewriting an API-compatible script in a different language is made easier, as it avoids the awkward situation where would be written in the baz language.