[Debian-med-packaging] Bug#667161: Language extensions in scripts (Was: Bug#667161: FASTX-Toolkit faisl to build with GCC-4.7)

[Andreas Tille]

Hi,

as it seems necessary to bring up this discussion again, I'd like to
give some reasons why policy states something that makes sense and it is
not in the interest of users to have those language extensions.

On Fri, Apr 27, 2012 at 08:37:08AM +0900, Charles Plessy wrote:
> Le Thu, Apr 26, 2012 at 10:21:53PM +0200, Andreas Tille a écrit :
> > 
> > When preparing the recent package I noticed that you are providing
> > scripts featuring language extensions (.pl and .sh).  Debian Policy[1]
> > says:
> > 
> >     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.
> > 
> > and there are several good reasons to follow this advise.  Could you
> > imagine to drop this extension in the script names - IMHO this would be
> > a good idea as long as fastx-toolkit is 0.0.x numbered.
> 
> Dear Andreas and Gordon,
> 
> please do not change the names unless a transition period of 1-2 years
> is planned where both names are available together.
> 
> That recommendation of Debian Policy is a pure disaster, that makes Debian
> systems incompatible with all the rest of the world.

I do not think that policy really contains disastrous statements and
your statement about "incompatibility with the rest of the world" is a
bit overheated.  The only reason for incompatibility would be if we
would rename those scripts without any alternative but as you have
noticed I did not do this and the reason for this was exactly not to
become incompatible.

To stay compatible we as the maintainer of a set of programs do have
some obligation to also teach authors of software what might be good or
not.  I admit I was a bit short in my initial mail and just stated that
there are several good reasons.  So I try to give some of them here now:

 1. http://en.wikipedia.org/wiki/Filename_extension#Command_name_issues

   "The use of a filename extension in a command name appears
    occasionally, usually as a side effect of the command having been
    implemented as a script (in Bourne shell, Python, etc.) and the
    interpreter name being suffixed to the command name, a practice common
    on systems like Windows and Mac OS X, which rely on globally set
    associations between filename extension and interpreter, but sharply
    deprecated in UNIX-derived systems like Linux and Apple's Mac OS X,
    where the interpreter is normally specified as a header in the script.
     ...
   "

 2. http://www.talisman.org/~erlkonig/documents/commandname-extensions-considered-harmful

    ... very reasonable and sane explanation of the problem leading to the
        consequence:

   "Commands should never have filename extensions.

    Rely on interpreter directives instead or some other paradigm that
    prevent the implementation from being exposed, or worse yet, lied about,
    within the very name of the command.
   "

 3. http://lists.debian.org/debian-policy/2003/04/msg00031.html

    This was one of first hits of numerous others on Debian lists which
    possibly leaded to the entry in Debian policy.  The reasoning was
    certainly influenced by the knowledge given above and expresses the
    fact that people might assume a user has understand the things above
    and regards scripts featuring extensions are rather simple examples,
    code snippets or whatever and not fully grown programs.  Somebody
    might not consider your code as honest tool or whatever.

 4. In addition I do not see what actual information such extensions are
    providing to the end user.  A user expects a program to do a job.
    Fullstop.  The user does not need to care about the language a program
    is written in if it just does what it is expected to do.  An extension
    at best means more typing work (and yes, I do know enouth users
    specifically working in the field of biology who do not know tab
    extension and when called in scripts - which is basically the only
    problem of a renaming you need to type the extension anyway).

    In the same way I'm always voting against program descriptions which
    are telling something like
      "Foo is a programm written in bar to do foobar"
    and would always vote to rather write
      "Foo does foobar {in a specific manner/like baz/... some other
        useful information for the user}"
    The programming language is just developer oriented metainformation
    with no additional value for the user who is interested in the
    functionality of the program.

In short: The goal of Debian (policy) is not to make Debian incompatible
with the rest of the world.  It rather intends to spread knowledge about
agreed principles into the world.  When writing mails like this I try to
do my obligation as Debian maintainer.  And yes, for sure some migration
path might make sense.  In this sense my wording about 0.0.x numbered
versions should have been understood.  It is quite usual that projects
change their interface when increasing their version numbers and users
should be aware of this.  My reasoning was not in the sense of Debian
but rather in the interest of fastx-toolkit.

Kind regards

       Andreas.

-- 
http://fam-tille.de