Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

[Charles Plessy <plessy@debian.org>]

Dear all,

my question triggered a lot of answers… In this message, I will first make a
few clarifications, then try to summarise, and conclude with my own opition.

First, I would like to underline that I am not questionning how applications
should be named, or whether Debian maintainer who chose to rename applications
whose suffix indicates their language should stop to do so. What I am asking is
whether the advantages of renaming always balance the inconveniences in such a
systematic way that not renaming is a bug for which there is most often no
excuse. Rephrased more formally, I would like the ‘should’ request to rename in
the Policy 10.4 to be either softened or removed.

Some people expressed opinions in this discussion which either support my point
of view [1,2], or suggest that the issue of this debate is open [3,4,5].

[1] http://lists.debian.org/msgid-search/20090929062143.GA5792@sumost.ca
[2] http://lists.debian.org/msgid-search/4AC20F1A.1000103@glondu.net
[3] http://lists.debian.org/msgid-search/87fxa560x9.fsf@windlord.stanford.edu
[4] http://lists.debian.org/msgid-search/20090929094727.GA7923@pcpool00.mathematik.uni-freiburg.de
[5] http://lists.debian.org/msgid-search/1254218108.19307.21.camel@shizuru

One of the biggest problems of renaming programs is that it breaks systems [6]
as well as documentation [7]. In case of online documentation, we can not
correct it.

[6] http://lists.debian.org/msgid-search/1254217244.28005.5.camel@fsopti579.F-Secure.com
[7] http://lists.debian.org/msgid-search/200909292045.35783.david.goodenough@btconnect.com

The typical way Debian deals with renaming programs is to keep the original
name in a separate directory, to be added in the PATH environment variable [8].
This of course has to be documented to the user [9], and it not scalable in
practice [10]. In a long-term solution, we could use the Blends framework to
group links to original program names in single directories that fit
specialised user audiences [11].

[8] http://lists.debian.org/msgid-search/4AC1C7F7.5010705@free.fr
[9] http://lists.debian.org/msgid-search/20090929112219.GA17947@an3as.eu
[10] http://lists.debian.org/msgid-search/0090930060257.GD24953@glandium.org
[11] http://lists.debian.org/msgid-search/20090930064251.GB22027@an3as.eu

All of the above is extra work for the maintainer and the user, and the major
reason that is invoked to justify renamings is that this work charge has anyway
to be taken any time if the program is re-implemented in a different language
[12]. It has also been suggested that it is the resposability of the
distributor, not the author, to make sure that the upstream project is easily
forkable [13]. This is actually the part I question the most: in the case of
the programs I package, I think that such a fork or language change is unlikely
and I am comptetely reluctant to spend some time preparing for it. Also, the
Policy only focuses on one part of the problem, tolerating prefixes but not
suffixes [14], so if it is not a bug to distribute a program called perlfoo, why
is it the case with foo.pl?

[12] http://lists.debian.org/msgid-search/87fxa560x9.fsf@windlord.stanford.edu
[13] http://lists.debian.org/msgid-search/4AC1FD0D.2000305@debian.org
[14] http://lists.debian.org/msgid-search/4AC26FA2.5050009@sunrise.ch

The energy we spend changing file names or arguing that we should not change
them would of course be spared if upstream authors would not use names like
perlfoo, qtbar, baz.app etc. But once a program is released, renaming it does
break things on the user side, and this is for this reason that I am not
willing to ask upstream to rename. If Debian some day publishes a list of
universal best practices, I will be of course be happy so send a link to it
Upstream, and suggest them to follow it for their next project. Of course,
writing such a document is a real challenge, and as an illustration it was
pointed that suffixes are necesary on Windows [15], an operating system that
many Upstreams are committed to support.

[15] http://lists.debian.org/msgid-search/Windows 4AC26FA2.5050009@sunrise.ch

The requirement in the chapter 10.4 of the Policy was added in a top-down
approach, with no consideration for the extra work it gives to the maintainers
and users [16, 17].

[16] lists.debian.org/msgid-search/20030418032551.GA13656@dragon.kitenet.net
[17] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=190753

As a user of my own packages, I am annoyed by the renaming of upstream programs
and I will stop following this Policy directive. In my opinion, the choice is
to be left to the maintainer, and this is not well reflected by using a
’should’ directive in the Policy. I would like to see it rephrased as a best
practice or removed.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan