[ On Wed, December 16, 1998 at 12:03:08 (-0800), I presume I need no introduction. wrote: ]
> Subject: Re: Package Paths Proposal v2
>
> 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?).

Well, actually, as soon as you end up with a heterogeneous network (from
the CPU architecture point of view) then your 99.9% of the way to ending
up with slightly different OS versions on each architecture, and then
all of a sudden you'll want a shared /usr/share for each OS version
(eg. so that you get the right manual pages with the right release).

In the end it's simpler just to forget about /usr/share being shareable
amongst heterogeneous systems.

(and I'm yes, I'm arguing against my own original, moot, points!  ;-)

I still like the concept of /usr/share, but I don't think it has any
practical advantage to a systems administrator -- it's really just a way
of helping a developer to think about what an object really is.  In
reality /usr/libdata does about as good a job.

> 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.

Exactly.  My sample product was fingerd.  If I want to install it in
place of the system fingerd I have to do so from the original source.

>  * 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.
 
Ah, but that doesn't mean all those vendors are "right" just because
they do similarly silly things!  ;-)

(note that if you want to be pedantic there's stuff in /sbin that should
really be in /libexec as it's not *really* meant to be invoked manually)

As I said, why do you want a smaller root filesystem on an already
stable production server?  /usr is just as stable as / (if not more so
as there are no config files being edited there!  ;-).  There's no
logical reason to separate /bin and /usr/bin in a stable production
environment.  It only helps developers who don't want to put all their
eggs in one basket.

Even application developers can have an extremely stable /usr if they
make /usr/local and/or /usr/pkg and/or /opt or /pkg into separate
filesystems.

Perhaps the GNU folks are overly optimistic about how soon their systems
can be put into stable production environments, but they *are* on the
"right" track.

> 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.

Ah, that's not correct.  From hier(7):

/usr/sbin	system daemons and system utilities (normally executed
		[[only]] by the super-user)
 
([[only]] added by me!  ;-)

Originally, when Unix ran on PDP-11's, /bin and /usr/bin were separated
out for "space" considerations and in theory to speed up PATH searching
because searching two directories was faster than searching one too big
of a directory, but that was a long time ago!

SunOS-4 was actually going in the right direction by moving /lib/* to
/usr/lib and /bin/* to /usr/bin, but they didn't go far enough
(i.e. they didn't force admins to give up on having a separate /usr
filesystem), so they ended up with a very complex and sometimes unstable
mess (not to mention the mess they left between /etc and /usr/etc!).

AIX has also move /lib/* to /usr/lib and /bin/* to /usr/bin, but again
they didn't make it illogical or difficult to create a /usr filesystem.
On AIX-4 /usr/etc is a mostly redundant and unused set of symlinks, so
it's not quite as bad on that front....  They kept all the symlinks to
programs in /etc though, so didn't really clean things up much.

I wish I had have understood all of these issues back when I first
encountered SunOS-4 and AIX!

I often thought SunOS-4 et al should have gone the other way and moved
/usr/bin/* to /bin; and /usr/lib/* to /lib/*, etc., totally eliminating
/usr and leaving "The System" on the root filesystem.  Perhaps a symlink
"/usr -> /home" would have made the change complete.  This is what the
GNU system will actually do (actually they're going to have "/usr -> /").
I like this idea a great deal, but changing any *BSD to do this would be
"difficult", to say the least.  I'll be satisfied for now with just
merging the / (root) and /usr filesystems on stable production servers.

> [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.]

Exactly, and there's no logical difference between "system" config files
and "package" config files.  "package" is only a way of saying that it
didn't come from the systems, but when you have system and package
source there's no reason way any given package couldn't be a turned into
a part of the system (as is already done with "contributed" software in
NetBSD), so making any distinction between "system" and "package"
configuration files for the purpose of deciding whether or not they can
be shared is ludicrous.

> 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.)

I wouldn't if I were you.  That's not really any different from always
logging in directly as root.  You should make yourself 101% aware of
when you're running something abnormal, such as directly from libexec,
namespace collisions aside; just as you should use "su" to become root.

I've even heard people argue that root shouldn't put /sbin and /usr/sbin
in "his" PATH!  (I don't put them in my personal PATH, so I've become
accustomed to typing full pathnames for such things and can get by quite
well, even under stress, as root with just PATH=/bin:/usr/bin, and on
almost any kind of Unix system too.)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>