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 reasonin
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 o
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[
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
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.
>
> Tha
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 whet
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
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 qmai
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?
T
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
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
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
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.
>
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
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, the
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 upstr
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 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
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 res
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 warn
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
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 p
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 apprec
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 c
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
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
* 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
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
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 comman
"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
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. T
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 w
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 th
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 co
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 colleagu
35 matches
Mail list logo
