[ On Tuesday, March 18, 2003 at 15:59:24 (-0800), Sean J. Schluntz wrote: ]
> Subject: Re: why separate system and pkg hierarchies? (was: /usr/pkg/etc/rc.d/*) 
>
> How does putting the packages in /usr/pkg make anything harder
> on the users?  Don't you supply the users with default shell files
> which have the path in them already?  If the path is there a user
> doesn't care where the binary is. All the users care about is whether
> or not the app works when the command is typed.

If only the world were so simple!

The first problem is that a vast majority of users who go so far as to
customise their own ~/.profile will do so in such a way that they don't
take advantage of any initial settings from /etc/profile.  I've seen
this way too many times in many different environments to believe it's a
rare thing and that users can somehow be magically trained to not get
themselves into such a situation.

The problems are of course much more prominent when those users have the
"pleasure" of using a variety of different systems which each come with
different base system components and which have add-on components
installed in different places.  Homogeneity can mask many problems.

Many people have complained about these kinds of differences for many
years -- probably ever since there were at least two competing base
systems with different sets of pre-integrated tools!

> Also, I have a reason to keep the binaries seperate, directory bloat.
> Have you actually taken count of how many binaries you would end up
> with if you put them all in the same dir on a heavily used box?

Yes, but this is best done based on function, not origin.  Put your X11
stuff in one place (/X11/bin), your sysadmin-only stuff in another place
(/sbin), and all your common user applications in yet another (/bin),
and that's separation (more than) enough.

Note that keeping things that are used together in the same place
actually improves performance.  Although I don't have the data any more
I have measured the difference between having everything in /usr/bin
vs. having separate /usr/bin and /usr/local/bin and I can assure you
that on any modern filesystem it is better to keep just one bin
directory rather than spreading things out into multiple directories.
You'd have to well exceed many tens of thousands of programs in a single
directory on a heavily used system before there would be any overall
system throughput improvement gained from splitting those programs
arbitrarily between two directories.

> I (for one) am happy with the /usr/bin, /usr/local/bin, /usr/X11/bin,
> /usr/pkg/bin thing.  I have also not gotten one single complaint 
> from any of the users of my systems, ever, since I provide them
> with profiles that work with the system that had to do with the
> location of files (naming, use of, version, that I have had complaints
> on, but never location).

That's not a fair comparision.  You need to expose those users to a set
of systems where all the add-on stuff is equally well integrated into
the system as the base tools are.  Then only after those users have had
some experience on such a tightly integrated system can you fairly ask
them for their opinion of having stuff arbitrarily scattered amongst
/usr/bin, /usr/pkg/bin, /usr/local/bin, and so on.

I happen to have a small set of users who first used SunOS-4 systems I
built many years ago where everything was very pedantically separated by
origin first and function second, with even /var and /local/var and so
on.  Those same users now use NetBSD systems where I've installed all
packages with PREFIX=/usr (initially fudging things like /usr/etc with a
symlink to /etc, and so on, though hopefully soon I can rely on
PKG_SYSCONFDIR=/etc and similar).  Those users all _very_ much
appreciate not having to worry about where something is installed for
any reason whatsoever.  These users know that if a command comes up "not
found" it's simply because it's not installed and they don't worry any
more that it might be installed in some other location that's not in
their $PATH.  They also don't have to worry about fixing up their
private scripts when they move them from a system where perl is in
/usr/pkg/bin and one where it's in /usr/bin, etc.  I think a couple of
them would even like to get rid of the sbin-bin separation, though
that's mostly because they often use some sbin tools even when not su'ed
to root which really only suggests those tools are mis-classified.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>