RFC

[Jim Knoble]

På 2000-Mar-16 klokka 12:47:07 +1000 skrivet Daniel Bradley:

: In a networked environment it would be better for a lot of the
: packages currently in /usr to be installed in /opt. Why?
: 
: Because, if a distribution installation is allowed to overwrite
: /usr then /usr shouldn't be networked. Or from the other angle,
: if you want (after an installation) to mount /usr, then its a
: waste of time and local disk resources to have the installation
: install in a local /usr. See NOTE 1.

This is a problem the distributions need to solve.  The LSB should not
`legislate' a solution.  Let's spend our efforts doing things more
crucial.

: To save disk space many things can be shared, as /usr/local
: should be local to a machine, /opt is the natural place for such
: sharing to occur.

Actually, /usr/ is really supposed to be the preeminent sharable
hierarchy.  That's why all the mutable stuff got moved to the /var/
hierarchy (e.g, logs moved from /usr/adm/ to /var/log/, mail spools
moved from /usr/spool/mail/ to /var(/spool)?/mail/, etc.), and why
architecture-independent stuff lives in /usr/share/ while
architecture-dependent stuff lives in /usr/lib/.  Putting `local'
system-specific binaries in /usr/local/ is nonsensical; then you end up
having to export /usr/bin/, /usr/lib/, and /usr/share/ separately (not
to mention /usr/X11R6/ and whatnot).

Here's what should be done with /usr/local/:

  rm -rf /usr/local/

System-specific binaries (and libraries and scripts and configuration)
ought to go in a completely different tree.  Sun's /space/local/ would
work, as would a simple /local/ (which is what i use).

As for what should be in /bin/, what in /usr/bin/, and what should live
elsewhere, may i remind folks of the problem of managing PATHs,
MANPATHs, INFOPATHs and whatnot as things already stand.  Managing
environments where a large portion of the software accompanying the
system gets installed into /opt/package-n.mm/{bin,info,lib,man,share}/
could become catastrophically difficult for admins of a large site.  I
think imposing such requirements on distribution-makers is a lose-lose
situation for both them and their customers.  It's quite enough for the
LSB spec to say what *should* live in /(s)?bin/ and /usr/(s)?bin/ and
leave the distribution-makers free to innovate and choose what's best
for their customers about what else accompanies the system and where it
lives.

That sort of freedom and innovation is what brought us useful tools
such as:

  - SysV-style init scripts that are actually useful and don't require
    sleight-of-hand backquote magic to manage services;
  
  - an /etc/ld.so.conf and /sbin/ldconfig that are also actually useful
    and no longer require the wretched cruft exemplified by -R/-runpath
    on Solaris, not to mention the unbelievable behavior of the AIX
    linker; and

  - filesystem structures where you don't have to hunt around /etc/,
    /usr/etc/, /usr/lib/, /usr/local/etc/, and /usr/local/lib/ before
    you find that config file you're looking for---you *know* it's
    going to be somewhere in /etc/.

: Personally I think it would be good that if you accidentely
: destoryed your root partition, you didn't have to overwrite
: 500+MB of perfectly fine /usr during a reinstall. :)

Machines, busses, and storage devices are all large and fast enough
nowadays that an extra 15 minutes and 500 MB are trivial.  If you trash
only your root partition by mistake, those extra 15 minutes will help
you remember not to do again next time.  If it's the disk's fault, you
really should be replacing the disk anyway.  If it's because your
machine was cracked or trojaned, you ought to be spending too much time
trying to track down the unwelcome visitor to care about those extra 15
minutes.  Get over it.

: NOTE 1: That said, if you want to mount /usr you might want a
: subset of /usr on your local machine for redundancy, so that if
: your network falls over you can still get a system running.

Nothing that is required to get a system running without a network has
any business even being in the /usr/ hierarchy.  If you need it to get
a system running, it needs to live in /bin/.  Plain and simple.

-- 
jim knoble
jmknoble at pobox.com