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

Fri Apr 27 09:15:54 UTC 2012

Dear Gordon,

sorry for exposing our disagreements.  I have transferred the discussion in
another bug report.  Feel free to follow it if you are curious, and do not
hesitate to give your opinion.

  http://bugs.debian.org/190753#139

Have a nice day,

-- Charles

Le Fri, Apr 27, 2012 at 08:59:46AM +0200, Andreas Tille a écrit :
> 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
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-med-REQUEST at lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster at lists.debian.org
> Archive: http://lists.debian.org/20120427065944.GH26037@an3as.eu

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan