Re: Policy §10.4 as a d ivergence from usptrea m (renamings to remove extensions like .pl and .sh).
On Wed, Sep 30, 2009 at 08:02:57AM +0200, Mike Hommey wrote: That would mean a possibly overlong PATH. A single place for those scripts would be better. That's what I meant when I wrote /usr/not_policy_compliant_named_dust-bin/ [1] I kept on thinking about this issue and I wonder whether there is a chance to find a pragmatical solution in the Blends scope. Knowing that the initiator of this thread comes form Debian Med Blend and considering the fact that you might frequently find specific applications in a certain field and external scripts / programs that are using this API in the same field of work. Moreover the Blends maintainer team has control or at least a good overview about the packages in the field. So we might do the following: 1. Install the policy compliant named executable to /usr/bin 2. Symlink to this from /usr/share/Blendname/bin with the name choosen by upstream. 3. Use /etc/profile.d/Blendname to extend the path (I just realised that lsb-core package installs /etc/profile.d and notice that the suggestion I wanted to make here is just implemented. I definitely have to read about its usage but it is exactly what I wanted to implement to extend the PATH reasonably.) There are plans to differentiate system users of a machine whether they should get the Blend specific settings or not. Currently this is implemented for the user menu system based on users in /etc/passwd but this method sucks for several reasons and has to be enhanced. But a way to do this settings for a certain set of users will be implemented sooner or later - so the question if everybody gets this PATH extension should be dealt with in the future. Kind regards Andreas. [1] http://lists.debian.org/debian-devel/2009/09/msg01016.html -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Policy §10.4 as a d ivergence from usptrea m (renamings to remove extensions like .pl and .sh).
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
Re: Policy §10.4 as a d ivergence from usptrea m (renamings to remove extensions like .pl and .sh).
On Thu, Oct 01, 2009 at 10:28:38AM +0900, Charles Plessy wrote: 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. Charles, thanks for the summary. 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. This is also an important point I wanted to rise (but just forgot). Currently every single maintainer is forced to invent a convincing text to educate upstream. The position of a single maintainer could be drastically strengthened if there would be a widely accepted document (not only in the Debian world) which gives a clear reasoning. Writing such a document and finding agreement in several distributions is challenging - but IMHO a reasonable step if we want to stick to our policy in the current form. Relaxing the policy as Charles proposed might be the alternative. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Policy §10.4 as a d ivergence from usptrea m (renamings to remove extensions like .pl and .sh).
On Tue, Sep 29, 2009 at 10:40:23AM +0200, Vincent Danjean wrote:
It is also possible to add symlinks into a private directory. Users willing
to use names with extensions only have to add this directory to their PATH.
For example, you can ship:
/usr/bin/util
/usr/share/package/bin/util.sh - /usr/bin/util
But this will break the interface for users as well as long as they not
explicitely extend their path to
/usr/share/{packages_with_extensions_in_names}/bin
The only way to not break the interfaces is to invent a dir say
/usr/not_policy_compliant_named_dust-bin/
and move everything there ans set the policy compliant links to /usr/bin.
Not that I would be in favour of this suggestion but this is the only
way I would see to let things work out of the box if you globally set
your PATH to this dir.
Users willing to use names with extension on Debian only have to do
PATH=/usr/share/package/bin:$PATH
The problem is: A user has to read the docs before and adding this to
the PATH explicitely is as easy as learning about a renamed executable.
The goal is to let things work out of the box.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
