Greg A. Woods sez:
/*
 * However sharing /usr/share in heterogeneous networks is harder to set up
 * (conceptually so, even more so, with it being under /usr) and doesn't
 * really offer much value in today's environment.  In reality every
 * diskful server is likely to have it's own local copy of /usr/share
 * anyway.

Your first point is moot.  What's stopping /usr/share from being exported
from a server as it is?  It's not enough of an effort to whinge about.

Your second point regarding value is also moot -- /usr/share is quite
concise and it lives on /usr as a separate filesystem (like you, I _like_
lots of filesystems :-).  It has quite a bit of value in my eyes anyway.

Your third point about every diskful server being likely to have its own
local copy is a reasonable assumption.  However, anyone with any reasonable
intelligence who is setting up a networked environment is probably going
to want to share /usr/share among all architectures (that _is_ the idea
of /usr/share, is it not?).

If I found myself with an unstable server, I'd probably be wont to put
/usr/share on each workstation, but that's the extent of that.

 * > 
 * > No.  If something wants to replace system binaries in /bin and /sbin, its
 * > behavior is spelled out here, via the move-and-symlink item.

[or the dump-and-pkg_add procedure :-)]

I'm thinking it's simply easier to reconfigure in /etc than to replace
a system binary.

I *do* see some problems with replacing things in /usr/libexec; I don't
think the pkg system does anything with that particular directory --
at least, I haven't found it yet.  This is problematic for things that
4.4 BSD expects to find in certain places, such as fingerd, rshd, et al.

 * This isn't "easy" to do for some packages, esp. those that compile in
 * their paths.  For example GNU Autoconf coding standards don't expect a
 * separate /sbin and /usr/sbin, and anyone wanting to replace a system
 * binary will have to jump through extra hoops if they're using autoconf.

That's just foolishness on GNU's part, then, because even Sun uses separate
/sbin and /usr/sbin, albeit in a limited context.  This is true also of
AIX, HP-UX and IRIX, last I looked.

 * For example I've "autoconf'ed" a fingerd replacement.  I still don't
 * really know how I'd properly patch that thing to work with pkgsrc.  I
 * think anything that expects this to work right iwht pkgsrc will have to
 * have additional gunk in the pkgsrc Makefile or some additional install
 * script in the files subdir.

That's what the command line option --prefix=DIR is all about, and I believe
the pkg system will interface rather nicely with this.

 * I.e. if pkg is to follow hier(7) to the letter then it must be a
 * *complete* mirror and include $PREFIX/usr/sbin as well as $PREFIX/sbin.

This is a debate on semantics.  /sbin and /bin live on root to make the
minimally stable bootable repairable system in the smallest possible amount
of space.  /usr/sbin and /usr/bin are separated out for space considerations.

[I won't repeat my rant on why SunOS from 4.x on were stupid to require
 /usr to be mounted at boot time.]

 * As has been mentioned it would be *insane* for the pkg system to provide
 * a solution for sharing pkg config files, but not a solution for sharing
 * system config file.  Anyone who *knows* what they're doing, and *still*
 * wants to share *some* config files will almost always want want to share
 * some system config files too, and if the pkg system provides a
 * hard-coded solution to this problem it will likely clash with what they
 * want to do.  This requirement should *not* be dealt with here.

What I read this as saying is "pkg should not be telling us how to share
system config files".  If this is what you're saying, I will deduce your
race to be human [q.v. Douglas Adams' Hitchhiker's Guide five-book trilogy].

[Personally, system config files shouldn't be shared at all -- it leads to
massive confusion if one system is to be pretending to be another.  Better
to have copies in this case.]

 * > Um, they shouldn't go directly under $PREFIX/sbin - talk about `littering
 * > namespaces'.

I was going to say, "This is not such a horrible idea," until it dawned
on me that daemons, for the most part, should live in /usr/libexec, not
<wherever>/sbin.  (Yes, they're able to be called "by hand", but don't we
only do that when we're troubleshooting...?).

[Sorry about all the 'I's in this letter; unless someone dies, here,
 my experience overall won't catch up with the rest of the seasoned
 veterans.  However, it's come to my attention that I'm not blowing total
 smoke.]

FWIW, 4.4 BSD->{Net|Free|O.*}BSD have the most sane hierarchy I've
seen.  When I first read about it, I thought, "Ew.  They're moving
admin binaries out of /etc and into this new place called /sbin?  And
what's /var, and /usr/share?  Ew."  And then the light glimmered, and
it was good.  :-)  I've not had a second thought or indirect regret since.

 * *I* don't really care about "littering namespaces" actually.  I got over
 * that idea way back when C permitted the same field names to be used in
 * multiple structs, if not before.

Well, _someone_ had to do something sensible with programming languages.

 * But anyway, who said the name of the program in $PREFIX/libexec has to
 * be the same as the name of the wrapper script in $PREFIX/sbin?????

Do we USE ${PREFIX}/libexec?

 * the silly fools are putting libexec directories in their PATH when they
 * shouldn't be).

Bingo.  (Also s/when/where/ as appropriate.  Being a systems admin type,
I put /usr/libexec as the last element in my path.  It's not unheard of.)

 */





				--*greywolf;
--
"Come, or we shall be late."  "Late for what?"  "What is your name?"  "Dent.
Arthur Dent."  "Late, as in 'the late Dentarthurdent'."