FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 12-12-2008, 08:30 PM
Ansgar Burchardt
 
Default 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
 
Old 12-12-2008, 09:54 PM
Drake Wilson
 
Default 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
 
Old 12-13-2008, 08:18 AM
Bas Zoetekouw
 
Default 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
 
Old 12-13-2008, 08:45 AM
Russ Allbery
 
Default 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
 
Old 12-13-2008, 11:59 AM
Ansgar Burchardt
 
Default 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
 
Old 12-13-2008, 01:21 PM
"Paul Wise"
 
Default 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
 
Old 12-13-2008, 07:52 PM
Russ Allbery
 
Default 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
 

Thread Tools




All times are GMT. The time now is 08:59 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org