On Sun, Jun 16, 2002 at 01:48:21AM -0500, Branden Robinson wrote:
> On Sun, Jun 16, 2002 at 03:16:12PM +1000, Anthony Towns wrote:
> > On Thu, Jun 13, 2002 at 01:17:45PM -0500, Branden Robinson wrote:
> > > > So why waste everyone's time discussing it rather than just using sed
> > > > or /bin/sh and getting on with your life?
> > > Because this isn't just about me, and it isn't just about cut(1).[1]
> > cut was what was brought up. Do you really care about ddate being in
> > /bin rather than /usr/bin?
> No. Is it your position that every executable from an Essential package
> that isn't already in /sbin or /sbin is as frivolous as ddate?
> If not, why imply it?
I'm sorry if you're unable to understand my inferences. That particular
one was that not all programs in essential packages need to be in
/bin. One of dpkg, update-rc.d or ddate ought to be enough of an example
to demonstrate that without going off on too much of a pointless tangent.
If you don't want to claim that all programs in essential packages need
to be in /bin or /sbin, then you've established two things:
* that "minimal" means different things when talking
about the contents of /bin and /sbin compared to the contents
of essential packages
* that programs that do go in /bin or /sbin need stronger
recommendations than just "they're important enough to be in
an essential package".
> > > It's about what authors of early-running init scripts in general can
> > > expect to have at their disposal.
> > They can expect to have what they absolutely need, and pretty much nothing
> > else.
> So, rather than establishing any guidelines for what they're going to
> "absolutely need", we'll just tell them that what they "absolutely need"
> is whatever happens to be in /bin or /sbin today.
No, we'll tell them to use their common sense. You don't absolutely need
cut, since you can use sed instead.
> > If there's something cut can do that sed can't that's absolutely
> > needed by an init script that needs to run before /usr's mounted it'd
> > be reasonable to move it. If it's just a nuisance to have to learn a
> > different tool, well, that's not a reason to move cut.
> s/cut/$anything/
If you're going to try to generalise a concrete example at least do it
right:
s/cut/<some tool proposed to be added to /bin>/g
s/sed/<any tool already in /bin or /sbin>/g
s/an init script/<a program>/g
> And if the package maintainer disagrees?
Which package maintainer?
> > > > > The set of files provided by Debian's Essential packages is, in
> > > > > fact, minimal.
> > > > Depends what you mean.
> > > Yup. So what *does* Debian mean?
> Interesting that you didn't bother to propose an answer to this.
Interesting that you *still* haven't noticed that it's an ambiguous
question, that *can't* be answered (correctly) until you clarify what
you mean.
> > The items listed above are ones that generally need to be in essential
> > packages. Particularly perl, sort, tr and kin. That is to say, they need
> > to be available for the Debian packaging tools to function.
> That's the definition of an Essential package, not the definition of a
> "minimal" Debian system.
A minimal Debian system is one that has all the essential packages
installed with their dependencies satisfied (so libc6 and mawk and such
as well).
This has nothing to do with the contents of /bin or /sbin. It has to do with
the fact that the word "minimal" is used in different contexts.
Do you realise that sash.deb provides /bin/sash and is priority: optional?
> > If they're not in /usr, they're off-limits.
> As are the POSIX utilities for determining whether or not they're in
> /usr.
*shrug* POSIX has absolutely no relevance here.
> > And the burden of proof lies on you to demonstrate why you absolutely
> > must have any particular one available beforehand.
> Translation: the intersection of all Essential package maintainers'
> opinions shall determine what will be possible before /usr is mounted.
Well, no. The original was in English, so you don't need to translate it
at all. If you want something added to /bin or /sbin that's currently
under /usr, *YOU* have to provide a convincing argument as to why it
needs to be moved.
As opposed to complain about how there's no convincing argument as to
why it's where it is.
> > Further, /bin/bash is available and provides both type and test as
> > builtins.
> Bad news for any Debian port that wants to use ash as its Essential
> shell, then.
Well, yes. bash is Essential: yes, and may be assumed to be present on
all Debian systems. If some port wants to change that assumption they
get to clean up the mess.
> > OH NO! THERE'S _NO OFFICIAL LIST_!!! THEREFORE EVERYTHING I SAY MUST BE
> > WRONG!!!! OH WOE IS ME!!!!!!
> We have neither a list nor a set of guidelines documented anywhere as to
> what the maintainer of an early-running init script can expect to
> accomplish. Instead, he has to experiment, [...]
Or he could ask on -mentors or -devel if he can't figure out how to use
the tools in /bin and /sbin to do what he wants.
> Why do you find it so abhorrent to document the assumptions we are
> making about the system before /usr is mounted? What is the utility of
> a clubhouse mentality in the root partition?
"a clubhouse mentality", eh? The reason things aren't moved willy-nilly
from /usr is to keep the root partition as small as possible. This has
various benefits for various people which I'm sure you could find with
a little research.
> Documentation good. Ad hockery bad.
That's your opinion, not mine, and not the word of God that you make it
out to be.
> > or dismissing reasonable objections out of hand ("I invite your
> > participation if you have something to contribute beyond "don't do
> > that, then.").
> "Don't do that, then" is not a reasonable objection.
Again, it is. If there's a simple alternative that works and doesn't
put any burden on others, it's the thing to do.
If you're just asking for a clarification on why some things go in /bin
and others go in /usr/bin, you should be asking on the -mentors list.
> > Sometimes the status quo happens to be quite a good compromise of all
> > the various interests at stake.
> And sometimes it isn't. If I were to attempt to move the XFree86
> executable into /usr/bin,
The correct analogy would seem to be "If someone asked me to move the
XFree86 executable into /usr/bin,"
> I'd expect to hear something better in the way
> of an objection than a retreat to circular terminology.
And, indeed, I'd certainly expect you to hear a good justification for
such a change. OTOH, if you as package maintainer chose to do such a
thing, I'd assume you already had such a justification, and hope that
you'd worked out how to avoid any significant breakage as well.
> "It's not minimal."
> "What do you mean by 'minimal'?"
> "It's not essential."
> "What do you mean by 'essential'?" "It's not minimal."
Whether something goes in /bin or /sbin has nothing to do with whether it's
in an "Essential: yes" package.
> > > Given the tone of your reply, Anthony, that means you.
> > Ah, yes, clearly your lack of satisfaction with things means others should
> > be proactive in providing for your happiness.
> Debian Developers should be proactive in creating a better system for
> everyone, including novice or inexperienced developers who turn to the
> Policy Manual for guidance.
You'll note that a current complaint against the policy manual is that it's
too verbose.
> When the Policy Manual fails to offer them
> guidance, they need to hear something better than, "uh, er, well, don't
> do that, then."
"Use sed instead, and get on with your life."
> However, in the course of researching the problem I encountered our
> current handling of the disction between executables in /usr and /,
> which appears to be driven wholly by personal fiat and/or accident.
And the problem with this is what exactly?
There're over 15,000 open bugs in Debian at the moment, are _any_ of
them caused by inconsistent placement of binaries in /bin and /usr/bin?
> I
> think the availablity of minimal^Wessential^Wwhatever system
> functionality is too important to be left to fiat,
How about we try replacing the word "fiat" with "the good judgement of
the relevant maintainers". That would be the same maintainers (yourself
and Herbert) who managed to figure out that moving cut to /bin wasn't
the right solution in this case, eg.
Hopefully saying the above isn't going to be taken as someone's cue to
treat calling my bluff as more fun that actually showing some common
sense and we won't end up with /bin/twm or similar. [0]
> and that we should
> document the undocumented assumptions and reasoning that have led us to
> the status quo, so that we can collectively make better decisions in the
> future.
If you're that enthused about documenting stuff, then please go ahead and
document it. If you want to save others the annoyance you've suffered,
that's fine, work out how to document and send in a patch. This isn't
what you've done: you've brought your argument with Herbert out onto a
list inviting participation, and you've tried to demand that I write up
some documentation.
> I have grown accustomed to your distaste for any proposal or discussion
> that increases the accessibility of the Debian distribution to
> maintainers who have not already attained positions of privilege, and
> the accountability of those individuals to the Project as a whole.
> I have grown even more accustomed to your substitution of belittling,
> petty remarks for rational discourse.
Ones like the above, then?
Cheers,
aj
[0] cf Bug#97040
--
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:
pgp4OBQBc_jOP.pgp
Description: PGP signature