= Proposal: stop removing language extensions from script names =

Currently, the Policy's section 10.4 contains:

    ''When scripts are installed into a directory in the system PATH, the
    script name should not include an extension such as .sh or .pl that
    denotes the scripting language currently used to implement it.''

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

    ''Non-conformance with guidelines denoted by should (or recommended) will
    generally be considered a bug, but will not necessarily render a package
    unsuitable for distribution.''

As a consequence, programs with names such as ''foo.pl'' 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 ''foo.bar'' 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, ''foo.py'' becomes ''foo.pl'', 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 ''foo.bar'' would be written in the ''baz'' language.