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?
> > 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.
> 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/
And if the package maintainer disagrees?
> > > > 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. I
infer that what Debian means is whatever is in /bin or /sbin today,
which can change.
> 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.
> > Are all of the above necessary for "minimal operations"? Certainly not.
>
> But they don't need to be available to mount /usr. Whether they're
> needed for "minimal" operations depends on which of those options you're
> referring to.
What options are we willing to support in our minimal system? Shall we
just leave this undefined and say, "well, whatever you can manage to
accomplish with whatever happens to be in /bin or /sbin today"?
> If they're not in /usr, they're off-limits.
As are the POSIX utilities for determining whether or not they're in
/usr.
> 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.
> > Given that test and which are extremely useful for figuring out what's
> > on the system for control flow purposes,
>
> If you're running before /usr's mounted, you're using stuff from /bin
> or /sbin, so there's not a huge amount of benefit to being able to
> figure out where you're running from.
Where I'm "running from"? I was unaware that test(1)'s utility was so
limited.
> 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.
> 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, and do one of several things
when his experiments fail:
1) give up
2) plead with the maintainer of an Essential package to accomodate him
3) rewrite his init script to use different utilities
4) rewrite his init script in perl
5) compile his init script as an ELF executable
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?
> > What can early-running init scripts, not to mention sysadmins
> > ACTUALLY TRYING TO RECOVER A SYSTEM, rely upon to be present?
>
> Depends how badly your system's screwed. In some cases you can't rely
> on anything working (libc6 is screwed, sash isn't installed, the kernel
> got corrupted, you have a hardware failure...).
Of course. Not only are you arguing for a very low threshold above
which the root partition is totally useless (i.e., many failure
scenarios render the system unbootable to a multi-user runlevel) and
thus increasing the need for a rescue disk, you're arguing that we
shouldn't even be telling people what informs our reasoning why the bar
is set where it is.
For instance, netcat recently moved its executable (nc) from /usr/bin to
/bin. If another Debian developer disagrees with that, on what grounds
would he object? Does he have a leg to stand on? Surely there must
*some* criteria we apply to keep things out of the root partition.
(For the record, I don't object to /bin/nc, and I think it's a good
idea. But this is probably just evidence of moral turpitude.)
Documentation good. Ad hockery bad.
> Then maybe you should consider actually having a discussion about
> it,
As opposed to raising the issue for discussion in the debian-policy list
with "RFD" in the subject line, eh?
> rather than, say, appealing to scripture at every chance you can
> ("the Debian Policy Manual's [judgement]"
The Debian Policy Manual is scripture now? I thought it was a
collaboratively authored document that describes (for the most part)
Debian-specific interfaces that further the goal of smooth Debian
package interoperation and functionality. (It also does a bit of
double-duty as a "best current practices" document.)
> or "Where's the official list of utilities needed to recover a
> system[?]")
How kind of you to exclude the part where, alternatively, I called for a
description of the principles we use to populate /bin and /sbin.
> 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. It offers
absolutely nothing in the way of explanation, and is the retort of those
who either do not have, or are not willing to communicate, a logical
justification for their position.
> 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, I'd expect to hear something better in the way
of an objection than a retreat to circular terminology.
"It's not minimal."
"What do you mean by 'minimal'?"
"It's not essential."
"What do you mean by 'essential'?" "It's not minimal."
Repeat ad nauseum.
> > 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. When the Policy Manual fails to offer them
guidance, they need to hear something better than, "uh, er, well, don't
do that, then."
> If you have a problem with some particular program being in /bin instead
> of /usr/bin or vice-versa, discuss it with the maintainer and provide a
> convincing argument why it shouldn't be where it is.
This is only an appropriate recourse if only the individual package
maintainer's judgement is material to the decision.
Or can I put twm in /bin and not expect to hear any complaints from you?
> Or don't, run off to mummy, or -policy or the tech-ctte
It is instructive that you regard all of these as equivalent.
> and whine about how no one ever plays fair with you like you usually
> seem to.
Had you bothered to read any of the source material I referenced, you'd
learn that the immediate problem with the discover package's init script
has been resolved, and was solely due to my mistaken understading of how
update-rc.d works.
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. I
think the availablity of minimal^Wessential^Wwhatever system
functionality is too important to be left to fiat, 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.
> Whatever.
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.
--
G. Branden Robinson |
Debian GNU/Linux | Cogitationis poenam nemo meretur.
[EMAIL PROTECTED] |
http://people.debian.org/~branden/ |
pgp56HTtL17pq.pgp
Description: PGP signature
