Re: renaming scripts provided by upstream
Bas Zoetekouw <firstname.lastname@example.org> writes:
> You wrote:
>> Quoth Ansgar Burchardt <email@example.com>, 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.
PGP: 1024D/595FAD19 739E 2D09 0969 BEA9 9797 B055 DDB0 2FF7 595F AD19