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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
