Andreas Tille andr...@an3as.eu 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
On Tue, Sep 29, 2009 at 10:59:03PM +0200, Frank Küster wrote:
David Goodenough david.goodeno...@btconnect.com 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
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
On Tuesday 29 September 2009, Frank Küster wrote:
David Goodenough david.goodeno...@btconnect.com 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
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
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
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
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
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
Steve M. Robbins st...@sumost.ca 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
On Tue, Sep 29, 2009 at 07:30:44PM +1000, Ben Finney wrote:
Steve M. Robbins st...@sumost.ca 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
On Tue, 2009-09-29 at 19:30 +1000, Ben Finney wrote:
Steve M. Robbins st...@sumost.ca 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
* Mike Hommey m...@glandium.org [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
Mike Hommey m...@glandium.org writes:
On Tue, Sep 29, 2009 at 07:30:44PM +1000, Ben Finney wrote:
Steve M. Robbins st...@sumost.ca writes:
I agree with Charles: this is unncessary, unproductive busy-work.
The same characterisation could be given to other changes that raise
the
Peter Eisentraut wrote:
On Tue, 2009-09-29 at 19:30 +1000, Ben Finney wrote:
Steve M. Robbins st...@sumost.ca 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.
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
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
Le mardi 29 septembre 2009 à 13:21 +0800, Paul Wise a écrit :
On Tue, Sep 29, 2009 at 1:09 PM, Reinhard Tartler siret...@debian.org 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
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 -
Quoting Josselin Mouette j...@debian.org:
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
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 siret...@debian.org wrote:
Would you consider this a blocker to inclusion into Debian? Upstream may
either release very slowly or may just not care about
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
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
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
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
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
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
Peter Eisentraut pet...@debian.org 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
On Tuesday 29 September 2009, Russ Allbery wrote:
Peter Eisentraut pet...@debian.org 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
David Goodenough david.goodeno...@btconnect.com 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
John H. Robinson, IV jaq...@debian.org (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
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
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
Reinhard Tartler siret...@debian.org writes:
Paul Wise p...@debian.org 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,
34 matches
Mail list logo
