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.ga5...@sumost.ca [2] http://lists.debian.org/msgid-search/4ac20f1a.1000...@glondu.net [3] http://lists.debian.org/msgid-search/87fxa560x9....@windlord.stanford.edu [4] http://lists.debian.org/msgid-search/20090929094727.ga7...@pcpool00.mathematik.uni-freiburg.de [5] http://lists.debian.org/msgid-search/1254218108.19307.21.ca...@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.ca...@fsopti579.f-secure.com [7] http://lists.debian.org/msgid-search/200909292045.35783.david.goodeno...@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.5010...@free.fr [9] http://lists.debian.org/msgid-search/20090929112219.ga17...@an3as.eu [10] http://lists.debian.org/msgid-search/0090930060257.gd24...@glandium.org [11] http://lists.debian.org/msgid-search/20090930064251.gb22...@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....@windlord.stanford.edu [13] http://lists.debian.org/msgid-search/4ac1fd0d.2000...@debian.org [14] http://lists.debian.org/msgid-search/4ac26fa2.5050...@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.5050...@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.ga13...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
