Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

[Ben Finney]

Andreas Tille  writes:

> Currently every single maintainer is forced to invent a convincing
> text to educate upstream. The position of a single maintainer could be
> drastically strengthened if there would be a widely accepted document
> (not only in the Debian world) which gives a clear reasoning. Writing
> such a document and finding agreement in several distributions is
> challenging - but IMHO a reasonable step if we want to stick to our
> policy in the current form.

Perhaps  would be an appropriate
forum to attempt formulation of such a policy.

-- 
 \   “Liberty, n. One of imagination's most precious possessions.” |
  `\   —Ambrose Bierce, _The Devil's Dictionary_, 1906 |
_o__)  |
Ben Finney


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

Re: Policy §10.4 as a d ivergence from usptrea m (renamings to remove extensions like .pl and .sh).

[Andreas Tille]

On Thu, Oct 01, 2009 at 10:28:38AM +0900, Charles Plessy wrote:
> my question triggered a lot of answers??? In this message, I will first make a
> few clarifications, then try to summarise, and conclude with my own opition.

Charles, thanks for the summary.
 
> If Debian some day publishes a list of
> universal best practices, I will be of course be happy so send a link to it
> Upstream, and suggest them to follow it for their next project. Of course,
> writing such a document is a real challenge, and as an illustration it was
> pointed that suffixes are necesary on Windows [15], an operating system that
> many Upstreams are committed to support.

This is also an important point I wanted to rise (but just forgot).
Currently every single maintainer is forced to invent a convincing text
to educate upstream.  The position of a single maintainer could be
drastically strengthened if there would be a widely accepted document
(not only in the Debian world) which gives a clear reasoning.  Writing
such a document and finding agreement in several distributions is
challenging - but IMHO a reasonable step if we want to stick to our
policy in the current form.  Relaxing the policy as Charles proposed
might be the alternative.
 
Kind regards

 Andreas.

-- 
http://fam-tille.de


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

Re: renamings to remove extensions

[John H. Robinson, IV]

Steve Langasek wrote:
> On Tue, Sep 29, 2009 at 10:05:29AM -0700, John H. Robinson, IV wrote:
> 
> > /var/qmail/bin/qmail-send
> > /command/supervise
> 
> DJB bug.

The correct answer:
  Difference of opinion.
  
> (And a symlink doesn't make the software FHS-compliant.)

In the case of qmail-send[1], the binary lives in /usr/sbin, which is
FHS compliant. The symlink is to keep it DJB compliant.

 [1] and the rest of the qmail binaries

-- 
John H. Robinson, IV  jaq...@debian.org
 http  
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type.  spiders.html  


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

Re: Policy §10.4 as a d ivergence from usptrea m (renamings to remove extensions like .pl and .sh).

[Charles Plessy]

Dear all,

my question triggered a lot of answers… In this message, I will first make a
few clarifications, then try to summarise, and conclude with my own opition.

First, I would like to underline that I am not questionning how applications
should be named, or whether Debian maintainer who chose to rename applications
whose suffix indicates their language should stop to do so. What I am asking is
whether the advantages of renaming always balance the inconveniences in such a
systematic way that not renaming is a bug for which there is most often no
excuse. Rephrased more formally, I would like the ‘should’ request to rename in
the Policy 10.4 to be either softened or removed.

Some people expressed opinions in this discussion which either support my point
of view [1,2], or suggest that the issue of this debate is open [3,4,5].

[1] http://lists.debian.org/msgid-search/20090929062143.ga5...@sumost.ca
[2] http://lists.debian.org/msgid-search/4ac20f1a.1000...@glondu.net
[3] http://lists.debian.org/msgid-search/87fxa560x9@windlord.stanford.edu
[4] 
http://lists.debian.org/msgid-search/20090929094727.ga7...@pcpool00.mathematik.uni-freiburg.de
[5] http://lists.debian.org/msgid-search/1254218108.19307.21.ca...@shizuru

One of the biggest problems of renaming programs is that it breaks systems [6]
as well as documentation [7]. In case of online documentation, we can not
correct it.

[6] 
http://lists.debian.org/msgid-search/1254217244.28005.5.ca...@fsopti579.f-secure.com
[7] 
http://lists.debian.org/msgid-search/200909292045.35783.david.goodeno...@btconnect.com

The typical way Debian deals with renaming programs is to keep the original
name in a separate directory, to be added in the PATH environment variable [8].
This of course has to be documented to the user [9], and it not scalable in
practice [10]. In a long-term solution, we could use the Blends framework to
group links to original program names in single directories that fit
specialised user audiences [11].

[8] http://lists.debian.org/msgid-search/4ac1c7f7.5010...@free.fr
[9] http://lists.debian.org/msgid-search/20090929112219.ga17...@an3as.eu
[10] http://lists.debian.org/msgid-search/0090930060257.gd24...@glandium.org
[11] http://lists.debian.org/msgid-search/20090930064251.gb22...@an3as.eu

All of the above is extra work for the maintainer and the user, and the major
reason that is invoked to justify renamings is that this work charge has anyway
to be taken any time if the program is re-implemented in a different language
[12]. It has also been suggested that it is the resposability of the
distributor, not the author, to make sure that the upstream project is easily
forkable [13]. This is actually the part I question the most: in the case of
the programs I package, I think that such a fork or language change is unlikely
and I am comptetely reluctant to spend some time preparing for it. Also, the
Policy only focuses on one part of the problem, tolerating prefixes but not
suffixes [14], so if it is not a bug to distribute a program called perlfoo, why
is it the case with foo.pl?

[12] http://lists.debian.org/msgid-search/87fxa560x9@windlord.stanford.edu
[13] http://lists.debian.org/msgid-search/4ac1fd0d.2000...@debian.org
[14] http://lists.debian.org/msgid-search/4ac26fa2.5050...@sunrise.ch

The energy we spend changing file names or arguing that we should not change
them would of course be spared if upstream authors would not use names like
perlfoo, qtbar, baz.app etc. But once a program is released, renaming it does
break things on the user side, and this is for this reason that I am not
willing to ask upstream to rename. If Debian some day publishes a list of
universal best practices, I will be of course be happy so send a link to it
Upstream, and suggest them to follow it for their next project. Of course,
writing such a document is a real challenge, and as an illustration it was
pointed that suffixes are necesary on Windows [15], an operating system that
many Upstreams are committed to support.

[15] http://lists.debian.org/msgid-search/Windows 4ac26fa2.5050...@sunrise.ch

The requirement in the chapter 10.4 of the Policy was added in a top-down
approach, with no consideration for the extra work it gives to the maintainers
and users [16, 17].

[16] lists.debian.org/msgid-search/20030418032551.ga13...@dragon.kitenet.net
[17] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=190753

As a user of my own packages, I am annoyed by the renaming of upstream programs
and I will stop following this Policy directive. In my opinion, the choice is
to be left to the maintainer, and this is not well reflected by using a
’should’ directive in the Policy. I would like to see it rephrased as a best
practice or removed.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

[David Goodenough]

On Tuesday 29 September 2009, Frank Küster wrote:
> David Goodenough  wrote:
> > I am a newcommer to this particular bit of policy, but it occurs to me
> > that the answer is to add links to the original commands to conform to
> > Debian standards while leaving the upstream commands intact.
>
> That would horribly clutter the bin directories.  I think the approach
> with a /usr/share/$packagename/bin/ that contains the old names as
> links, and can be added to PATH, is the best we can do for supporting
> scripts that assume extensions.
Well of course we already do this aliasing with the alternatives system.
If this is only for those (hopefully) few where we can not persuade upstream
to cooperate would it really be that much of a burden?

David
>
> Regards, Frank
> --
> Dr. Frank Küster
> Debian Developer (TeXLive)
> VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
> B90/Grüne KV Miltenberg



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

Re: Policy §10.4 as a d ivergence from usptrea m (renamings to remove extensions like .pl and .sh).

[Andreas Tille]

On Wed, Sep 30, 2009 at 08:02:57AM +0200, Mike Hommey wrote:
> 
> That would mean a possibly overlong PATH. A single place for those
> scripts would be better.

That's what I meant when I wrote

/usr/not_policy_compliant_named_dust-bin/ [1]

I kept on thinking about this issue and I wonder whether there is a
chance to find a pragmatical solution in the Blends scope.  Knowing that
the initiator of this thread comes form Debian Med Blend and considering
the fact that you might frequently find specific applications in a
certain field and external scripts / programs that are using this API in
the same field of work.  Moreover the Blends maintainer team has control
or at least a good overview about the packages in the field.  So we
might do the following:

  1. Install the policy compliant named executable to /usr/bin
  2. Symlink to this from /usr/share//bin with the
 name choosen by upstream.
  3. Use /etc/profile.d/ to extend the path
 (I just realised that lsb-core package installs /etc/profile.d
  and notice that the suggestion I wanted to make here is just
  implemented.  I definitely have to read about its usage but
  it is exactly what I wanted to implement to extend the PATH
  reasonably.)

There are plans to differentiate system users of a machine whether they
should get the Blend specific settings or not.  Currently this is
implemented for the user menu system based on users in /etc/passwd but
this method sucks for several reasons and has to be enhanced.  But a
way to do this settings for a certain set of users will be implemented
sooner or later - so the question if everybody gets this PATH extension
should be dealt with in the future.

Kind regards

   Andreas.

[1] http://lists.debian.org/debian-devel/2009/09/msg01016.html

-- 
http://fam-tille.de


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

Re: Policy §10.4 as a divergence from usptrea m (renamings to remove extensions like .pl and .sh).

[Mike Hommey]

On Tue, Sep 29, 2009 at 10:59:03PM +0200, Frank Küster wrote:
> David Goodenough  wrote:
> 
> > I am a newcommer to this particular bit of policy, but it occurs to me that
> > the answer is to add links to the original commands to conform to 
> > Debian standards while leaving the upstream commands intact.
> 
> That would horribly clutter the bin directories.  I think the approach
> with a /usr/share/$packagename/bin/ that contains the old names as
> links, and can be added to PATH, is the best we can do for supporting
> scripts that assume extensions.

That would mean a possibly overlong PATH. A single place for those
scripts would be better.

Mike


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

Re: renamings to remove extensions

[Steve Langasek]

On Tue, Sep 29, 2009 at 10:05:29AM -0700, John H. Robinson, IV wrote:
> Mike Hommey wrote:

> > I do agree that if everyone but Debian expects foo to be called as
> > foo.pl, there is a bug in Debian.

> /var/qmail/bin/qmail-send
> /command/supervise

> These are what are expected when you use qmail and daemontools the DJB
> way. 

>   http://cr.yp.to/unix.html

> We solve the first one with /var/qmail/bin being a symlink to /usr/sbin.
> We don't solve the latter one at all.

> Debian bug, or DJB bug?

DJB bug.  (And a symlink doesn't make the software FHS-compliant.)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: renamings to remove extensions

[Cyril Brulebois]

John H. Robinson, IV  (29/09/2009):
> These are what are expected when you use qmail and daemontools the
> DJB way.
> 
>   http://cr.yp.to/unix.html
> 
> We solve the first one with /var/qmail/bin being a symlink to
> /usr/sbin.  We don't solve the latter one at all.
> 
> Debian bug, or DJB bug?

The Debian bug is to have anything DJB-related in the first place.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

[Frank Küster]

David Goodenough  wrote:

> I am a newcommer to this particular bit of policy, but it occurs to me that
> the answer is to add links to the original commands to conform to 
> Debian standards while leaving the upstream commands intact.

That would horribly clutter the bin directories.  I think the approach
with a /usr/share/$packagename/bin/ that contains the old names as
links, and can be added to PATH, is the best we can do for supporting
scripts that assume extensions.

Regards, Frank
-- 
Dr. Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg


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

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

[David Goodenough]

On Tuesday 29 September 2009, Russ Allbery wrote:
> Peter Eisentraut  writes:
> > At least in cases where the programs/scripts could be considered part of
> > a programming interface, this requirement is approximately equivalent to
> > requiring the exported symbols of libraries to conform to some spelling
> > scheme.  While Debian has occasionally altered or broken the exported
> > interfaces of libraries in cases of severe trouble, this is not
> > routinely done, and usually not merely in the name of prettiness.
>
> The argument for the Policy change wasn't about prettiness, but rather
> about not encoding the implementation language into the interface name.
> When the shell script named foo.sh gets rewritten into Perl, having it
> stay foo.sh or be renamed to foo.pl are both kind of broken.
>
> That may not be a good enough argument to continue this policy, but that
> was the argument for why it's now in Policy.
>
> --
> Russ Allbery (r...@debian.org)   

I am a newcommer to this particular bit of policy, but it occurs to me that
the answer is to add links to the original commands to conform to 
Debian standards while leaving the upstream commands intact.  This 
would then also mean that any documentation or howtos or tutorials
or blogs written around the upstream commands will still work.  Otherwise
not only does Debian have to modify the commands but also all the
documentation and write its own howtos and blogs.  Also somehow
we would need to subvert Google so it finds our copies for Debian users.

David

David


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

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

[Russ Allbery]

Peter Eisentraut  writes:

> At least in cases where the programs/scripts could be considered part of
> a programming interface, this requirement is approximately equivalent to
> requiring the exported symbols of libraries to conform to some spelling
> scheme.  While Debian has occasionally altered or broken the exported
> interfaces of libraries in cases of severe trouble, this is not
> routinely done, and usually not merely in the name of prettiness.

The argument for the Policy change wasn't about prettiness, but rather
about not encoding the implementation language into the interface name.
When the shell script named foo.sh gets rewritten into Perl, having it
stay foo.sh or be renamed to foo.pl are both kind of broken.

That may not be a good enough argument to continue this policy, but that
was the argument for why it's now in Policy.

-- 
Russ Allbery (r...@debian.org)   


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

Re: renamings to remove extensions

[Manoj Srivastava]

On Tue, Sep 29 2009, Josselin Mouette wrote:

> Le mardi 29 septembre 2009 à 11:43 +0200, Mike Hommey a écrit : 
>> Improving quality only for the sake of it is not necessarily a good
>> idea. I do agree that if everyone but Debian expects foo to be called
>> as foo.pl, there is a bug in Debian.
>
> Which is why lintian warnings are left at the appreciation of the
> maintainer.
>
> Renaming binaries in a way that breaks interfaces or expectations is not
> desirable, of course. That doesn’t prevent the goal of removing useless
> script extensions from being a worthy one.

Damn. Must be a cold day in hell, since I am on the same page here.

> The idea of putting extensions in scripts is stupid; it denotes a lack
> of understanding of the Unix way, and makes it harder to make them
> evolve in the future. Which is why we should remove these extensions
> when possible, and ask upstream to do so when it is not.

Also, it breaks encapsulation; and makes it unnecessarily hard
 to re-implement the functionality in a different language (unless one
 thinks it is a good idea to have a python script have the name foo.sh).

manoj
-- 
This was the most unkindest cut of all. William Shakespeare, "Julius
Caesar"
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: renamings to remove extensions

[Manoj Srivastava]

On Tue, Sep 29 2009, Mike Hommey wrote:


>> Improving quality may be strictly unnecessary, and may be not directly
>> productive, but that doesn't mean there's no good reason to expect it.
>
> Improving quality only for the sake of it is not necessarily a good
> idea. 

!!!

If we are trying to provide the best OS ever, improving quality
 is _always_ a good idea. It might be too hard, or too time consuming,
 to implement all the quality improvements, but that does not make the
 improvement of quality "not a good idea".

> I do agree that if everyone but Debian expects foo to be called as
> foo.pl, there is a bug in Debian.

I think I disagree.  As my mother used to say, if all your
 friends jump into the well, that does not make it a good idea.

manoj
-- 
"The one charm of marriage is that it makes a life of deception a
neccessity." Oscar Wilde
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: renamings to remove extensions

[Manoj Srivastava]

On Tue, Sep 29 2009, George Danchev wrote:

> I've also read people claiming that preserving extensions could
> actually help evolving and migrations in the future and it is as
> simple as app.lang1 being rewritten as app.lang2, both stay on board
> as needed or for a reasonable amount of time, then at some point
> app.lang1 could actually be changed to just call app.lang2 when it's
> considered mature enough. That is absolutely fine with me as long as
> app.* are kept in reasonable amount of disk space, but scripts usually
> don't tend to become that large. (even small sizes could not be that
> practical for embedded when doubled, but that is another story).

Since it is  being claimed that the script name is an
 "interface" that other software uses, then basic encapsulation 101 says
 that one should maintain the interface, but not rely on implementation
 (which, in the case of scripts, includes the language the script is
 implemented in).

manoj
-- 
But Officer, I stopped for the last one, and it was green!
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

[Manoj Srivastava]

On Tue, Sep 29 2009, Abou Al Montacir wrote:

> You can also try to make the world look like you want not adapt your
> eyes to see the world as is, no?

We try to fix the world, yes. Systems integrations, and
 consistent policies, is what make Debian a superior OS.

> Please note that upstream could not adapt themselves to all distribution
> policies which may be contradictory, but a distribution could and
> probably should adapt itself to upstream.

A distribution should not adapt itself to 1 different
 upstreams with different polices, that would be a inconsistent madness,
 and would serve our end users ill. Part of what we do as Debian
 maintainers is to make software fit better with other bits of Debian,
 and this we do by creating and following a technical policy.

manoj
-- 
We don't care how they do it in New York.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: renamings to remove extensions

[John H. Robinson, IV]

Mike Hommey wrote:
> 
> I do agree that if everyone but Debian expects foo to be called as
> foo.pl, there is a bug in Debian.

/var/qmail/bin/qmail-send
/command/supervise

These are what are expected when you use qmail and daemontools the DJB
way. 

  http://cr.yp.to/unix.html

We solve the first one with /var/qmail/bin being a symlink to /usr/sbin.
We don't solve the latter one at all.

Debian bug, or DJB bug?

-- 
John H. Robinson, IV  jaq...@debian.org
 http  
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type.  spiders.html  


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

What is this rule for? (was: Re: renamings to remove extensions)

[Andreas Tscharner]

On 29.09.2009 08:21, Steve M. Robbins wrote:


On the other hand, Section 10.4 says only "the script name should not
include an extension".  So you can leave the extension for


What is the intention of this rule anyway?

Thank you and best regards
Andreas
--
Andreas Tscharner
--
"Intruder on level one. All Aliens please proceed to level one."
  -- Call in "Alien: Resurrection"


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

Re: Policy §10.4 as a divergence from usptr eam (renamings to remove extensions like .pl an d .sh).

[Giacomo A. Catenazzi]

Abou Al Montacir wrote:

Le mardi 29 septembre 2009 à 13:21 +0800, Paul Wise a écrit :

On Tue, Sep 29, 2009 at 1:09 PM, Reinhard Tartler  wrote:


Would you consider this a blocker to inclusion into Debian? Upstream may
either release very slowly or may just not care about Debian, which
would result in the package to never end up in Debian.

I'd consider not fixing it in the .deb (irrespective of what upstream
does) as a blocker.

Having an uncooperative upstream would likely make me think twice
about putting it in Debian in the first place.


You can also try to make the world look like you want not adapt your
eyes to see the world as is, no?

Please note that upstream could not adapt themselves to all distribution
policies which may be contradictory, but a distribution could and
probably should adapt itself to upstream.

In addition, many of upstream won't change their work just because we
want them to do so because of our policy. In my case, I tried many times
and most of my tries failed. You can not force others to adopt the same
vision as you (at least in a democratic world).


IMHO this is not true. Look at Linux 10-15 years ago: it was completely
different: every program was different: different option conventions,
different commands to configure and build, different paths, different keys,
different interpretation of free software, etc.

Debian tried hard to standardize such things, and IMHO because of Debian
(or with some Debian help) a lot of things changed.
Your arguments are old, but fortunately we look forward, and now we have
the open source definition, we have FHS, we have LSB, backspace/delete/C-H
have a consistent behaviour, we don't need to use any special environment
variable for any program, ...

It is not a different vision, but a forward looking: user are interested
in interfaces, not in the underlying details and languages. Thus
*in general* (there are always exceptions), the suffix causes difficulties
to reprogram the utility in an other language.

It is not the upstream task to simplify forks and concurrent utilities
(in an other language), so you cannot always agree/convince upstream
to remove suffix, but we will have do deal with such enhancements.

We cannot force the other to adapt to our vision, but we can have
a common vision. Users (and developers) have the choice of distributions.
Debian, unlike other old distribution, still exist, proving our vision
is good.


ciao
cate


PS: I see this issue the same as FHS (but one is about "path prefix",
and this in about suffix). Thus we experienced a lot on how to modify
upstreams (a lot of upstreams still don't know about FHS).


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

Re: renamings to remove extensions

[George Danchev]

Quoting "Josselin Mouette" :


Le mardi 29 septembre 2009 à 11:43 +0200, Mike Hommey a écrit :

Improving quality only for the sake of it is not necessarily a good
idea. I do agree that if everyone but Debian expects foo to be called
as foo.pl, there is a bug in Debian.


Which is why lintian warnings are left at the appreciation of the
maintainer.

Renaming binaries in a way that breaks interfaces or expectations is not
desirable, of course. That doesn’t prevent the goal of removing useless
script extensions from being a worthy one.

The idea of putting extensions in scripts is stupid; it denotes a lack
of understanding of the Unix way, and makes it harder to make them
evolve in the future. Which is why we should remove these extensions
when possible, and ask upstream to do so when it is not.


I've also read people claiming that preserving extensions could  
actually help evolving and migrations in the future and it is as  
simple as app.lang1 being rewritten as app.lang2, both stay on board  
as needed or for a reasonable amount of time, then at some point  
app.lang1 could actually be changed to just call app.lang2 when it's  
considered mature enough. That is absolutely fine with me as long as  
app.* are kept in reasonable amount of disk space, but scripts usually  
don't tend to become that large. (even small sizes could not be that  
practical for embedded when doubled, but that is another story).



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

Re: Policy §10.4 as a d ivergence from usptrea m (renamings to remove extensions like .pl and .sh).

[Andreas Tille]

On Tue, Sep 29, 2009 at 10:40:23AM +0200, Vincent Danjean wrote:
> It is also possible to add symlinks into a private directory. Users willing
> to use names with extensions only have to add this directory to their PATH.
> For example, you can ship:
> /usr/bin/util
> /usr/share/package/bin/util.sh -> /usr/bin/util

But this will break the interface for users as well as long as they not
explicitely extend their path to
   /usr/share/{packages_with_extensions_in_names}/bin
The only way to not break the interfaces is to invent a dir say

   /usr/not_policy_compliant_named_dust-bin/

and move everything there ans set the policy compliant links to /usr/bin.
Not that I would be in favour of this suggestion but this is the only
way I would see to let things work out of the box if you globally set
your PATH to this dir.
 
> Users willing to use names with extension on Debian only have to do
> PATH=/usr/share/package/bin:$PATH

The problem is: A user has to read the docs before and adding this to
the PATH explicitely is as easy as learning about a renamed executable.
The goal is to let things work out of the box.

Kind regards

 Andreas. 

-- 
http://fam-tille.de


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

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

[Abou Al Montacir]

Le mardi 29 septembre 2009 à 13:21 +0800, Paul Wise a écrit :
> On Tue, Sep 29, 2009 at 1:09 PM, Reinhard Tartler  wrote:
> 
> > Would you consider this a blocker to inclusion into Debian? Upstream may
> > either release very slowly or may just not care about Debian, which
> > would result in the package to never end up in Debian.
> 
> I'd consider not fixing it in the .deb (irrespective of what upstream
> does) as a blocker.
> 
> Having an uncooperative upstream would likely make me think twice
> about putting it in Debian in the first place.

You can also try to make the world look like you want not adapt your
eyes to see the world as is, no?

Please note that upstream could not adapt themselves to all distribution
policies which may be contradictory, but a distribution could and
probably should adapt itself to upstream.

In addition, many of upstream won't change their work just because we
want them to do so because of our policy. In my case, I tried many times
and most of my tries failed. You can not force others to adopt the same
vision as you (at least in a democratic world).

I consider this is a nice to have, that's all.

Abou Al Montacir,


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: renamings to remove extensions

[Josselin Mouette]

Le mardi 29 septembre 2009 à 11:43 +0200, Mike Hommey a écrit : 
> Improving quality only for the sake of it is not necessarily a good
> idea. I do agree that if everyone but Debian expects foo to be called
> as foo.pl, there is a bug in Debian.

Which is why lintian warnings are left at the appreciation of the
maintainer.

Renaming binaries in a way that breaks interfaces or expectations is not
desirable, of course. That doesn’t prevent the goal of removing useless
script extensions from being a worthy one.

The idea of putting extensions in scripts is stupid; it denotes a lack
of understanding of the Unix way, and makes it harder to make them
evolve in the future. Which is why we should remove these extensions
when possible, and ask upstream to do so when it is not.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

[Peter Eisentraut]

On Tue, 2009-09-29 at 13:36 +0900, Charles Plessy wrote:
> I know that there has already been much of talk about this, but I am am 
> getting
> more and more uncomfortable removing .pl or .sh extensions from programs when
> upstream does not.

At least in cases where the programs/scripts could be considered part of
a programming interface, this requirement is approximately equivalent to
requiring the exported symbols of libraries to conform to some spelling
scheme.  While Debian has occasionally altered or broken the exported
interfaces of libraries in cases of severe trouble, this is not
routinely done, and usually not merely in the name of prettiness.



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

Re: renamings to remove extensions

[Giacomo A. Catenazzi]

Peter Eisentraut wrote:

On Tue, 2009-09-29 at 19:30 +1000, Ben Finney wrote:

"Steve M. Robbins"  writes:


I agree with Charles: this is unncessary, unproductive busy-work.

The same characterisation could be given to other changes that raise the
quality of software in Debian (e.g. ensuring that commands are
accompanied by man pages, or that the package synopsis should not be
repeated in the extended description).


This is not a useful analogy.  Software will continue to work with or
without documentation or description.  Renaming programs breaks
interfaces.


I totally agree. For this reason the suffix must be removed!
Program interfaces remain, but implementation language changes
(see many "-ng" packages).

ciao
cate


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

Re: renamings to remove extensions

[Ben Finney]

Mike Hommey  writes:

> On Tue, Sep 29, 2009 at 07:30:44PM +1000, Ben Finney wrote:
> > "Steve M. Robbins"  writes:
> > 
> > > I agree with Charles: this is unncessary, unproductive busy-work.
> > 
> > The same characterisation could be given to other changes that raise
> > the quality of software in Debian (e.g. ensuring that commands are
> > accompanied by man pages, or that the package synopsis should not be
> > repeated in the extended description).
>
> None of these have an impact on *other* software. Renaming a file
> does.

Peter Eisentraut  writes:

> This is not a useful analogy. Software will continue to work with or
> without documentation or description. Renaming programs breaks
> interfaces.

This is a different complaint from “unnecessary, unproductive
busy-work”. I was answering only that complaint.

So, if the change can be made *without* breaking existing interfaces
(e.g. by providing a compatibility symlink to the suffix-less real
program file), then the “breaks interfaces” complaint is addressed and
is no longer an impediment to providing well-named program files.

-- 
 \“Holy contributing to the delinquency of minors, Batman!” —Robin |
  `\   |
_o__)  |
Ben Finney


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

Re: renamings to remove extensions

[Bernhard R. Link]

* Mike Hommey  [090929 11:43]:
> > Improving quality may be strictly unnecessary, and may be not directly
> > productive, but that doesn't mean there's no good reason to expect it.
>
> Improving quality only for the sake of it is not necessarily a good
> idea. I do agree that if everyone but Debian expects foo to be called
> as foo.pl, there is a bug in Debian.

If that is the case that only means that upstream should be educated and
one has to choose between keeping bugs to be compatible and creating
problems by fixing bugs. (File names is not the only case where fixing
bugs can cause problems even to an extend where in same cases not fixing
the bug can be the better solution).

Hochachtungsvoll,
Bernhard R. Link


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

Re: renamings to remove extensions

[Peter Eisentraut]

On Tue, 2009-09-29 at 19:30 +1000, Ben Finney wrote:
> "Steve M. Robbins"  writes:
> 
> > I agree with Charles: this is unncessary, unproductive busy-work.
> 
> The same characterisation could be given to other changes that raise the
> quality of software in Debian (e.g. ensuring that commands are
> accompanied by man pages, or that the package synopsis should not be
> repeated in the extended description).

This is not a useful analogy.  Software will continue to work with or
without documentation or description.  Renaming programs breaks
interfaces.


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

Re: renamings to remove extensions

[Mike Hommey]

On Tue, Sep 29, 2009 at 07:30:44PM +1000, Ben Finney wrote:
> "Steve M. Robbins"  writes:
> 
> > I agree with Charles: this is unncessary, unproductive busy-work.
> 
> The same characterisation could be given to other changes that raise the
> quality of software in Debian (e.g. ensuring that commands are
> accompanied by man pages, or that the package synopsis should not be
> repeated in the extended description).

None of these have an impact on *other* software. Renaming a file does.

> Improving quality may be strictly unnecessary, and may be not directly
> productive, but that doesn't mean there's no good reason to expect it.

Improving quality only for the sake of it is not necessarily a good
idea. I do agree that if everyone but Debian expects foo to be called
as foo.pl, there is a bug in Debian.

Mike


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

Re: renamings to remove extensions

[Ben Finney]

"Steve M. Robbins"  writes:

> I agree with Charles: this is unncessary, unproductive busy-work.

The same characterisation could be given to other changes that raise the
quality of software in Debian (e.g. ensuring that commands are
accompanied by man pages, or that the package synopsis should not be
repeated in the extended description).

Improving quality may be strictly unnecessary, and may be not directly
productive, but that doesn't mean there's no good reason to expect it.

-- 
 \“Choose mnemonic identifiers. If you can't remember what |
  `\mnemonic means, you've got a problem.” —Larry Wall |
_o__)  |
Ben Finney


pgpZfCOcoX2rn.pgp
Description: PGP signature

Re: Policy §10.4 as a divergence from usptr eam (renamings to remove extensions like .pl an d .sh).

[Vincent Danjean]

Charles Plessy wrote:
> I use the packages I made, and renaming upstream programs names makes my 
> scripts
> incompatible with my colleagues work environments using other distributions or
> installations from source. So as a maintainer, I spend time creating extra 
> work
> for myself as a user. That does not make sense.

It is also possible to add symlinks into a private directory. Users willing
to use names with extensions only have to add this directory to their PATH.
For example, you can ship:
/usr/bin/util
/usr/share/package/bin/util.sh -> /usr/bin/util

Users willing to use names with extension on Debian only have to do
PATH=/usr/share/package/bin:$PATH

  Regards,
Vincent


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

renamings to remove extensions

[Steve M. Robbins]

Hi,

I agree with Charles: this is unncessary, unproductive busy-work.

On the other hand, Section 10.4 says only "the script name should not
include an extension".  So you can leave the extension for
compatibility with the rest of the world.  It is a bug, but Section
1.1 says:

  Non-conformance with guidelines denoted by should (or recommended)
  will generally be considered a bug, but will not necessarily render
  a package unsuitable for distribution.

-Steve


signature.asc
Description: Digital signature

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

[Ben Finney]

Reinhard Tartler  writes:

> Paul Wise  writes:
> > So get upstream to change their filenames before packaging them for
> > Debian.
>
> Would you consider this a blocker to inclusion into Debian? Upstream
> may either release very slowly or may just not care about Debian,
> which would result in the package to never end up in Debian.

That doesn't prevent the maintainer from modifying the work to conform
with Policy though, so upstream's recalcitrance wouldn't be a blocker.

If upstream is actively *obstructing* the compliance with Debian policy
(by being hostile to the changes, or being unresponsive to change
requests) should be a factor in considering whether to maintain the
package at all; but that's a judgement the maintainer should make based
on their own frustration thresholds and available time.

-- 
 \  “[Entrenched media corporations will] maintain the status quo, |
  `\   or die trying. Either is better than actually WORKING for a |
_o__)  living.” —ringsnake.livejournal.com, 2007-11-12 |
Ben Finney


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

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

[Reinhard Tartler]

Paul Wise  writes:

>> I know that there has already been much of talk about this, but I am
>> am getting more and more uncomfortable removing .pl or .sh extensions
>> from programs when upstream does not.
>
> So get upstream to change their filenames before packaging them for Debian.

Would you consider this a blocker to inclusion into Debian? Upstream may
either release very slowly or may just not care about Debian, which
would result in the package to never end up in Debian.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

Policy §10.4 as a diver gence from usptrea m (renamings to remove extensions like .pl and .sh).

[Charles Plessy]

Dear all,

I know that there has already been much of talk about this, but I am am getting
more and more uncomfortable removing .pl or .sh extensions from programs when
upstream does not.

I use the packages I made, and renaming upstream programs names makes my scripts
incompatible with my colleagues work environments using other distributions or
installations from source. So as a maintainer, I spend time creating extra work
for myself as a user. That does not make sense.

Would it be possible to change our Policy and simply follow upstream choices?
Good arguments can be given for not including extension in program names
upstream, but in my opinion removing them before upstream creates more
problems than it solves…

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


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