Ansgar Burchardt writes:
> 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
On Sat, Dec 13, 2008 at 9:59 PM, Ansgar Burchardt wrote:
> 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 alre
Hi,
Bas Zoetekouw writes:
>
> You wrote:
>
>> Quoth Ansgar Burchardt , 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.
Bas Zoetekouw writes:
> 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 exception
Hi Drake!
You wrote:
> Quoth Ansgar Burchardt , 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
Quoth Ansgar Burchardt , 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 progra
l
that denotes the scripting language currently used to implement
it.
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 p
7 matches
Mail list logo