From: yee@mipgsun.mipg.upenn.edu (Conway Yee)
Newsgroups: comp.os.linux
Subject: A suggestion about the location of binaries
Date: 30 Sep 92 23:24:40 GMT
Organization: University of Pennsylvania

With respect to the latest flame war about /bin, /usr/bin, and
/usr/local/bin, I have a couple of comments to make.  Traditionally,
/bin and /usr/bin were OS vender supplied binary directories while
/usr/local/bin was a repository for locally derived binaries.  The
files in /bin /usr/bin were updated only sporadically with OS
upgrades.  Furthermore, since /usr was frequently a separate partition
from the root partition and is not mounted at bootup, the most
essential binaries (e.g. bin, cat, ls) were placed in /bin.  If there
was some sort of failure of mounting, at least something could be done
about it.  All remainder system binaries were placed in /usr/bin.

Today, with freely distributable OS's the mode of upgrade is
different.  As such, the above model for binaries is not totally
adequate.  Updates are probably more frequent and not all system
binaries are updated at the same time (e.g. there is a new release of
shellutils but not fileutils).  There should be some easy way to
upgrade on subset of binaries without upsetting the rest.
Furthermore, it should be readily apparent which binary came from what
package.  Binaries are no longer lumped in one large group called
"system binaries".  Binaries which could conceivably be in one of
several categories can be arbitrarily lumped into either one from of
utility or another.  On the other hand, some sort of compatibility
must be maintained.

Thus, I have a proposal.  Let us first define a few things.

#define BINARY usr/foo/bin   /*position of yet another binary directory*/

/BINARY must be in the same partition as /usr/bin.

Let suppose we have textutil-3.3/wc which we believe belongs in
/usr/bin.

Why can't we store the binary wc in /BINARY/textutil-3.3/wc ?  We
then softlink /BINARY/textutil-3.3 to /BINARY/textutil.  Finally we
create a softlink of /BINARY/textutil/wc to /usr/bin/wc.

Thus, /usr/bin/wc is actually points to /BINARY/textutil-3.3/wc via
/BINARY/textutil.

Thus, when textutil-3.4 comes in, we can compile it into
/BINARY/textutil-3.4 , change the softlink of /BINARY/textutil from
/BINARY/textutil-3.3 to /BINARY/textutil-3.4 rather easily.
/usr/bin/wc automatically points to the new binary.  The old binaries
are kept just in case there was a screwup and there is no fear of
missing an old binary in /usr/bin.  The only problem I see with this
is if the package textutil suddenly adds/deletes a command; it will
not be noticed until someone tries to execute it.

The same strategy can keep track of binaries which go into
/usr/local/bin.

The choice of what binaries go into /usr/bin and which go into
/usr/local/bin can be easily changed according to what is currently
politically correct :-)  Personally, I like system binaries in /usr/bin
and everything else (mostly packages) in /usr/local/bin.

The only exception to this system of softlinks is /bin These must be
the binaries themselves since softlinks may fail due to the failure to
mount the /usr partition.  In addition, no shared libraries can be
used.  A short script may be used to keep these up to date.


#define FLAME_RETARDENT

This is just a thought.  This is not a flame nor should it be
construed as a flame.  If you wish to flame me for this post, please
do so via email.  I am absolutely sure nobody in this newsgroup cares
to hear what kind of worm I am.  This is a suggestion which I would
like to put forth for criticism.

#undef FLAME_RETARDENT

-- 
411 Blockley Hall      |                    Conway Yee, N2JWQ
418 Service Drive      | yee@ming.mipg.upenn.edu    (preferred)
Philadelphia, PA 19104 | cy5@cunixa.cc.columbia.edu (forwarded to above)
(215) 662-6780         |