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-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/20120427065944.gh26...@an3as.eu -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
