Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   renaming scripts provided by upstream (http://www.linux-archive.org/debian-development/210981-renaming-scripts-provided-upstream.html)

Ansgar Burchardt 12-12-2008 08:30 PM

renaming scripts provided by upstream
 
Hi,

I wonder about the advantages and disadvantages of renaming scripts
installed in system PATH to not include an extension as ".pl"
(Policy 10.4):

When scripts are installed into a directory in the system PATH,
the script name should not include an extension such as .sh or .pl
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 programs to comply with the Debian naming scheme
creates new problems:

Documentation will usually refer to upstream's naming choice and we
cannot change online documentation or mailing lists. Even changing
only the documentation provided by Debian packages may require changes
to several packages.

What if scripts (or Makefiles) try to use the program? If they are
not written on a Debian system, they will not be aware of the different
name used there. The same applies to scripts written on Debian
systems: they will not work on other systems.

Some people think that divergence should be avoided (or at least be
merged with upstream if possible)[1]. In my opinion, renaming
binaries is a far more invasive change than many other small patches
applied to Debian's packages and *should* be avoided. Of course
convincing upstream to change the name is still okay :-)

Regards,
Ansgar

[1] http://lists.debian.org/debian-devel/2008/05/msg00536.html

--
PGP: 1024D/595FAD19 739E 2D09 0969 BEA9 9797 B055 DDB0 2FF7 595F AD19


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Drake Wilson 12-12-2008 09:54 PM

renaming scripts provided by upstream
 
Quoth Ansgar Burchardt <ansgar@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?

> Ansgar

---> Drake Wilson


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Bas Zoetekouw 12-13-2008 08:18 AM

renaming scripts provided by upstream
 
Hi Drake!

You wrote:

> Quoth Ansgar Burchardt <ansgar@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...

Regards,
Bas.


--
+--------------------------------------------------------------+
| Bas Zoetekouw | Sweet day, so cool, so calm, so bright, |
|--------------------| The bridall of the earth and skie: |
| bas@zoetekouw.net | The dew shall weep thy fall tonight; |
+--------------------| For thou must die. |
+-----------------------------------------+


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Russ Allbery 12-13-2008 08:45 AM

renaming scripts provided by upstream
 
Bas Zoetekouw <bas@debian.org> 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 exceptions to the rule.

The rationale is that programs are changed or reimplemented, and by adding
a file extension the implementation language becomes part of the API.
When foo.sh is rewritten in Python, do you keep calling it foo.sh and
confuse everyone, or rename it to foo.py and break all callers?

The implementation language shouldn't be part of the public API for a
command. The user doesn't care what language something is written in.

(There are exceptions, which is part of why it's a should and not a must.)

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Ansgar Burchardt 12-13-2008 11:59 AM

renaming scripts provided by upstream
 
Hi,

Bas Zoetekouw <bas@debian.org> writes:
>
> You wrote:
>
>> Quoth Ansgar Burchardt <ansgar@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

"Paul Wise" 12-13-2008 01:21 PM

renaming scripts provided by upstream
 
On Sat, Dec 13, 2008 at 9:59 PM, Ansgar Burchardt <ansgar@2008.43-1.org> 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 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 this case, asking upstream to rename the script would likely to be
the best option.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Russ Allbery 12-13-2008 07:52 PM

renaming scripts provided by upstream
 
Ansgar Burchardt <ansgar@2008.43-1.org> 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 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.

If that xgettext is really just a Perl version xgettext (in other words,
that it's written in Perl is really its primary distinguishing factor),
then I think this is one of those exceptions that are why Policy says
"should" instead of "must". I'd still rather see it called xgettext-perl
instead of xgettext.pl, but at that point it's really just an aesthetic
preference, which may not warrant diverging from upstream.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


All times are GMT. The time now is 06:50 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.