Hi, Bas Zoetekouw <b...@debian.org> writes: > > You wrote: > >> Quoth Ansgar Burchardt <ans...@2008.43-1.org>, on 2008-12-12 22:30:24 +0100: >> > I understand that it should not matter to the user what language is >> > used to implement a particular script and support omitting >> > extensions. But what about renaming scripts provided by upstream? >> > In this case renaming programs to comply with the Debian naming scheme >> > creates new problems: >> >> Not being well-acquainted with this bit, I can't comment very well on >> what Debian policy would say, but wouldn't using the upstream name >> plus a non-extensioned symlink solve several of these cases? > > I think policy tries make sure there are no "foo.pl" or "bla.sh" scripts > in the path, regardless of what they are symlinked to. I don't know > what the rationale behind that is though (apart from the ugliness). > And in any case, it's a SHOULD, so there can be exceptions to the rule. > > Ansgar, which package and binary is this about, in particular? That > info might make the question a bit more concrete...
liblocale-maketext-lexicon-perl ships a `xgettext.pl' which I would like to see installed in /usr/bin (#508505). In this case there is a small additional problem: just omitting the extension does not work because `xgettext' is already provided by gettext. It was suggested to rename `xgettext.pl' to something completely different (e.g. xgettext-lexicon or xmaketext), but as I said earlier I think it is not a good idea to rename programs only in Debian if it can be avoided. In any case, I think this is a more general problem because it breaks scripts using upstream's naming scheme and makes it harder for users to find programs as documentation will point to another name. Regards, Ansgar -- PGP: 1024D/595FAD19 739E 2D09 0969 BEA9 9797 B055 DDB0 2FF7 595F AD19 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
