Re: RFD: Essential packages, /, and /usr
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?
> 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. 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.
> > > The set of files provided by Debian's Essential packages is, in
> > > fact, minimal.
> > Depends what you mean.
> Yup. So what *does* Debian mean?
> > ddate, dpkg, dselect, factor, find, mawk, perl, sort, tr, tsort, uniq,
> > update-rc.d, whoami, xargs, and yes are all in essential packages and
> > in /usr/bin.
> As are logger, [...]
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.
> 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.
> Should every single one of these be off-limits to early-running init
> scripts and people attempting to recover their systems? I don't think
> so.
If they're not in /usr, they're off-limits. And the burden of proof lies
on you to demonstrate why you absolutely must have any particular one
available beforehand.
> 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. Further, /bin/bash is available
and provides both type and test as builtins.
> > Essential packages are the ones needed to maintain a Debian system;
> > utilities in /bin and /sbin are ones needed to recover a system.
> Okay, great. Where's our official list of utilities needed to recover a
> system.
OH NO! THERE'S _NO OFFICIAL LIST_!!! THEREFORE EVERYTHING I SAY MUST BE
WRONG!!!! OH WOE IS ME!!!!!!
> 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...).
> > > Are you suggesting that we substitute your judgement of
> > > what is "minimal" for the Debian Policy Manual's?
> > People like Herbert's judgement is what was used to write the policy
> > manual.
> I hate to break it to you, but I'm the author of several accepted policy
> proposals as well.
Then maybe you should consider actually having a discussion about
it, rather than, say, appealing to scripture at every chance you can
("the Debian Policy Manual's [judgement]" or "Where's the official list
of utilities needed to recover a system[?]") or dismissing reasonable
objections out of hand ("I invite your participation if you have something
to contribute beyond "don't do that, then.").
> > > I'm CCing debian-policy as a means of RFD. I invite your participation
> > > if you have something to contribute beyond "don't do that, then."
> > Sometimes "so don't do that, then" is the right answer.
> See above. All I hear from you are arguments for the status quo, [...]
Sometimes the status quo happens to be quite a good compromise of all
the various interests at stake.
> 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.
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. Or don't, run off
to mummy, or -policy or the tech-ctte and whine about how no one ever
plays fair with you like you usually seem to. Whatever.
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
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: