Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).
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 <siretart@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 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).
Reply to: