Subject: Re: Package Paths Proposal v2
To: NetBSD Packages Technical Discussion List <>
From: I presume I need no introduction. <>
List: tech-pkg
Date: 12/16/1998 12:03:08
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

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


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