On Thu, Jun 13, 2002 at 11:20:31PM +1000, Anthony Towns wrote:
> On Tue, Jun 11, 2002 at 12:35:27PM -0500, Branden Robinson wrote:
> > On Fri, Jun 07, 2002 at 02:55:23PM +1000, Herbert Xu wrote:
> > > Anyway, there are already plenty of tools in /bin capable of performing
> > > the task of cut(1).
> > Sure.
>
> 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]
It's about what authors of early-running init scripts in general can
expect to have at their disposal. Your answer is apparently "whatever
happens to be in /sbin and /bin and that's it". What if that changes?
See the bug logs of #149256 for more information. Here, I'll give you a
link:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=149256&repeatmerged=yes
> > 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, renice, replay, script, wall, savelog, sensible-editor,
sensible-pager, which (!), mkboot, cmp, diff, diff3, sdiff, dpkg-deb,
dpkg-split, md5sum, chattr, lsattr (hmm, good luck troubleshooting a
problem with a bad ext2 attribute flag to "recover a system"), uuidgen,
mklost+found, dircolors, du, install, link, mkfifo, shred, unlink,
rgrep, clear, infocmp, tack, tic, toe, tput, tset, basename, dirname,
env, expr, id, logname, patchchk, printenv, printf, seq, tee, test (!),
tty, whoami, hostid, nice, pinky, users, who, groups, nohup, [, chroot,
rmt, cksum, comm, csplit, cut, expand, fmt, fold, head, join, nl, od,
paste, pr, ptx, split, sum, tac, tail, unexpand, wc, md5sum.textutils,
chkdupexe, fdformat, getopt, ipcrm, ipcs, mcookie, namei, rev, setsid,
setterm, whereis, cytune, elvtune, readprofile, and tunelp.
Are all of the above necessary for "minimal operations"? Certainly not.
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.
Given that test and which are extremely useful for figuring out what's
on the system for control flow purposes, I'm amazed that someone would
argue that they are inessentials tools. Actually I'm not amazed; I've
grown quite accustomed to the argument that Debian developers should eat
what they're fed and like it, or at least keep their mouths shut about
it.
> 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. What can early-running init scripts, not to mention sysadmins
ACTUALLY TRYING TO RECOVER A SYSTEM, rely upon to be present?
If we expect admins to have a rescue disk available ("trying to recover
a Debian system with only /sbin and /bin? Don't do that, then."), then
your assertion about what's "minimal" is a red herring. We would not,
in fact, actually expect /bin and /sbin to be used for this purpose.
> > 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. If you feel my judgement is categorically suspect,
you should propose the repeal of all the amendments I've authored.
> > 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, and
the divine right of Essential package maintainers to put their
executables wherever they want, with no accountability to anyone. Let's
not have any critera for establishing what's minimal, and let's
certainly not have a list that would hamper Essential package
maintainer's discretion to act as they please.
No. Maintainers of Essential packages have a *greater* responsibility
to Debian developers and Debian users, *because* their packages are
always installed, and their functionality is fundamental. We must hold
these packages to higher standards than those which we apply to the ICQ
client of the week in extra.
Note: a simple list of the Essential package executables of /bin and
/sbin from the woody release, presented as a policy proposal, is a
perfectly legitimate response to my complaints. However, I'm not going
to be the one making that proposal because I feel that there are several
things which should be in /bin or /sbin that currently aren't. Someone
reading this list who believes firmly in the status quo should make that
proposal instead.
Given the tone of your reply, Anthony, that means you.
[1] Incidentally, the bug was closed -- and the issue is larger than
that of cut(1) and discover's init script -- because the bug submitter
had his copy of discover's init script running at the wrong priority.
This is because I misunderstood how update-rc.d works, which I raised as
a separate thread on debian-policy. Discover's init script is now fine,
but unfortunately discover's utility is therefore a little limited. It
would be nice to be able to have discover running earlier so that you
could use it to autodetect the device on which you're storing /usr.
(If the kernel can't already see it, it's manual intervention time.)
Until this policy issue is resolved, it will be very difficult to use
discover that way.
--
G. Branden Robinson | No math genius, eh? Then perhaps
Debian GNU/Linux | you could explain to me where you
branden@debian.org | got these... PENROSE TILES!
http://people.debian.org/~branden/ | -- Stephen R. Notley
Attachment:
pgpxySaTAUlNu.pgp
Description: PGP signature