On Sun, Jun 16, 2002 at 12:55:32PM -0500, Manoj Srivastava wrote:
> Nice polemics. But each side here has a modicum of logic on
> their side; Branden wants a nice, uncontroversial, black and white,
> writ in stone (well, may be not) list of commands available to
> maintainers of packages that appear early in the boot process, when
> parts of the standard system may not be populated. Merely looking at
> whether the package is Essential is not enough; since /usr is not
> mounted early in the boot process.
You are oversimplifying my argument.
I did not ask solely for a list of commands. Alternatively, I asked for
a list of criteria that are determinative of what sorts of tools Debian
puts in /sbin and /bin as opposed to /usr.
A list of criteria other than "just run for F in $(grep-available -F
Essential -s Package yes | awk '{print $2}'); do dpkg -L $F | egrep
'^/s?bin/.'; done", that is.
> The pro is obvious, one can then figure out easier how to
> package something like that, and perhaps even allocate fault in some
> packages with no argument whatsoever. The Con is that this list has
> to be maintained, and may be superfluous, and seems to be designed
> to be yet-another-stick-to-beat-recalcitrant-developers-with.
Straw man, as you are fond of saying. Given that no one has designed it
yet, how can you make assumptions about their motivations? Presumably,
were Anthony compelled to create such a list, he'd grant quite a bit of
latitude.
> (Superfluous how? just look at the cvontents of /bin and /sbin to
> determine whether to command is actually available that early in
> boot).
"Just run for F in $(grep-available -F
Essential -s Package yes | awk '{print $2}'); do dpkg -L $F | egrep
'^/s?bin/.'; done".
> Aj, on the other hand, is logically asking for continuing to
> use package priority
I thought he was asking that we use package essentiality, though I
suppose one could argue that "essential" is a virtual priority, one
higher than any others.
Alternatively, my grep-available command needs to be changed.
> and content of /bin and /usr as a guide, and
> asking for logical, and technically convincing reasons for changing
> the setup, and using these to obviate the need for the list. The con
> here is that since we are allowing people a modicum of free will,
> there shall be controversy.
The con is that a position analogous to library documentation saying
"the API is whatever happens to be in the header files today" needs to
be explicitly justified.
> As to the specifics of cut; I do not find any argument advanced
> so far that is convincing; I still think that a minimal / is a
> desired goal.
I've long since granted that cut is not an interesting example, at least
not the way I was using it.
If you're up to it, however, I would like to challenge you to implement
/usr/bin/tr(1) in /bin/sed(1). I few of us on IRC tried several days
ago to do it, and concluded that it couldn't be done.
> Of course, we can all admit we are wrong, Jeroen was write,
> and like the Hurd, do away with the silly /usr thang for once and for
> all.
I presume this is facetious because A) you mentioned Jeroen ;-) and B)
the Hurd's union mounts don't get you around the problem that / will
have more or less in it depending on how early in the boot sequence you
are. (At least, as I understand the Hurd, which is not very well.)
--
G. Branden Robinson | It's like I have a shotgun in my
Debian GNU/Linux | mouth, I've got my finger on the
branden@debian.org | trigger, and I like the taste of
http://people.debian.org/~branden/ | the gunmetal. -- Robert Downey, Jr.
Attachment:
pgpUN9Y120ndJ.pgp
Description: PGP signature