On Tue, Jun 18, 2002 at 08:13:19AM -0500, Steve Greenland wrote:
> On 17-Jun-02, 21:51 (CDT), Anthony Towns <aj@azure.humbug.org.au> wrote:
> > "It seems sloppy" is a pretty poor argument for moving every binary not
> > specifically mentioned in the FHS into /usr and gratuitously breaking
> > any scripts that needed them where they are.
> Yes, that would be a pretty poor argument, if I had indeed suggested
> doing that. But I didn't.
What you suggested was: "Early running init scripts can count on the
FHS required commands being in /bin:/sbin, and anything else might be
in /usr/bin:/usr/sbin".
Now, personally, I think that, by definition, early running init scripts
can count on the availability of any files provided by essential packages
and packages they explicitly depend on in /bin or /sbin. If that weren't
the case then either our packaging system has become fundamentally broken
and needs immediate fixing.
So the only real question is what files packages -- essential or not
-- should be putting in /bin or /sbin, and is the one I took you to
be addressing.
I certainly don't see the point of having packages put files in /bin,
and then avoid having scripts use them out of an absolutely baseless
fear that they might be moved.
> I haven't made any suggestions about moving
> anything. All I've suggested is that we list what early running code can
> rely on, and a couple of different ways to get there.
They can rely on programs in /bin and /sbin working as documented if
they're present. They can rely on them being present if the packages
that include them are specified as dependencies. What's difficult to
understand about this?
> > Are you sloppy when you exercise your judgement about your packages? Why
> > would you expect everyone else to be?
> I don't. However, we already have cases of specific developers being,
> shall we say, "difficult". Not sloppy, but having very strong opinions
> about how a particular thing should be done, despite a large number of
> other experienced developers disagreeing.
And? Have there been any actual bugs caused by the problem you're claiming
exists? Or are you upset at the idea that someone could strongly hold
an opinion you disagree with, and feel a need for someone to tell you
who's right and who's wrong?
That's meant as a serious question, not a taunt. It can be annoying in the
extreme to be disagreed with by people you'd otherwise like to respect,
but if there's no *technical* justification for a policy, it shouldn't
be made.
> What is the purpose of Debian Policy? I always thought it was a way to
> decide/document choices, when more than one choice was reasonable, and
> when that choice affected other developers and our users. This subject
> falls into that definition, in my opinion.
Debian Policy is *technical* policy. It's about making good packages, not
stopping people's feelings from being hurt. The developer's reference
contains some guidelines for the latter (about NMUs and suchlike),
if you really care, but there's a reason it's not considered nearly as
influential as policy.
If there's no technical reason for a policy -- if doing it one way or
the other doesn't make Debian appreciably better or worse -- it shouldn't
be in policy.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif
Attachment:
pgp1RH3ijlusC.pgp
Description: PGP signature