Software installation opinions needed

[Brian Hackworth]

In article <25908 at shamash.cdc.com>, ddh at hare.cdc.com (dd horsfall
x-4622) writes:
> Wisdom and/or insight needed.  Disclaimer: although I've worked in
the
> software development field for 15+ years, I'm (relatively) new (~2
yr)
> to the Unix variants.
> 
> If this is in one of The Fine Manuals, reference thereto would be
> appreciated, but I haven't found it yet.
> 
> Is there a "convention" (or even a "standard", who knows) which
defines
> the difference in content between  /bin, /usr/bin, /usr/local/bin,
> /usr/new, /usr/etc, /usr/5bin, /usr/sbin ... and so forth, all the 
> combinations that start with / and end with bin or lib?
> 

Ok, I'll bite.  You asked for mail, but I think this is
a topic of interest for most administrator types, so I'm
following up here.

The background for much of this discussion is the fact
that the industry is moving towards a client-server model
of computing, where software on a server is (or may be)
shared with zero or more operating system clients.

We can divide third party packages into two parts:
the part which is the same for all hosts, and is therefore
shared (an example is the /usr/bin/cat executable); and 
the part which is unique to each host (an example is 
/etc/passwd).

This breakdown maps to / (root) and /usr for vendor-supplied
software and /opt and /usr/opt for third-party-supplied
optional software.

Under the root directory, packages may have these directories
(as well as others, maybe):
    
    etc		- for host-specific data and configuration files
    
Under the usr directory, packages may have these directories:

    bin		- for user-visisble executable commands
    etc		- for host-independent data and configuration files
    lib		- for library data and routines
    catman	- for manual pages
    sbin	- for system (administrative) commands not
		    visible to ordinary users

Note that this convention puts all executables in "bin" and "sbin",
even though most unixes today have executables in etc and lib
as well.

> Context: we are about to release a software product which will
include
> the usual (for us) stuff: program binary, man pages, example problems,
> installation verification data; for each of these, do we
> a) recommend a particular directory for its installation?
> b) leave it up to each site/purchaser to figure out for themselves
>    what's best for their configuration?
> c) Some combination -- recommended location for those who don't want
to
>    think too hard about it, guidelines for the rest?
> 
> Software installation: should we
> a) _Move_ the program binary to a place where people expect to find
such
>    things (i.e., something that's probably already in their $path) ?
> b) Recommend adding a new directory to the $path?
> c) _Leave_ the binary in a product/version catalog, but build a link
to
>    it from the "preferred" place in the path?  Hard or soft link?

(a) (/usr/opt/<package> should be the recommendation) and (c).

I believe that vendors should have complete control of the / (root)
and /usr directories.  Third parties should load all software
into /opt and /usr/opt trees.  The installation process should
make links from the "usual" places (usually /usr/bin or /usr/catman
or whatever) to the package place.  For example, if your package's
main executable is called foobar, create a link from

    /usr/bin/foobar to /usr/opt/foobar/bin/foobar

The link should be a symbolic link because you have no idea
how the customer has partitioned file systems.  Symbolic
links will work across file systems; hard links will not.

As long as you load your software into your own tree, 
sophisticated administrators can "install" the software
anywhere they want by creating the appropriate symbolic
links.

Then, when the customer upgrades his vendor-supplied software,
your third-party software is not deleted, just the links
are deleted.  After upgrading, the customer re-installs
your software (without re-loading).

> 
> How many of your third-party (i.e., not vendor-supplied) products
fall
> into the above categories.  Which do you prefer?  Did someone provide
> an installation script (or even document) that would be an
> exemplary model for us to follow?  If so, would you send me a copy?
> 

#! /bin/sh

#  Installation (setup) script for foobar package

ROOT=${1:-/}		#  Allow setting up a client's root
USR=${2:-/usr}		#  Allow setting up another usr tree

PKG=foobar

MAN=F_man

cd ${USR}/bin
ln -s ../opt/${PKG}/bin/foobar foobar

cd ${USR}/catman
ln -s ../opt/${PKG}/catman/${MAN} ${MAN}


And so on -- you get the idea.

> Are there any specific "things" that an install script did that 
> particularly annoyed you?  In other words, complete this sentence:
> "Whatever you do, DON'T DO THIS..."

Don't
    - assume anything about file system layout
    - put host-specific information in usr
    - put executables in etc or lib
    - modify anything outside of your directory tree unless
	absolutely necessary.  If it is necessary, 
	CLEARLY document what is changed.
    - hard-code pathnames into executables

> 
> Lastly, what else in this area should I know that I don't even know
> that I don't know (as compared to the things that I know I don't
know)?
> 

It sounds to me like you are asking the right questions.

>  
> Readers with an opinion in the above areas are invited to reply to
the
> address in .sig; I can't imagine that a large number of general
> net.people have any interest in this...
>    The Horse
>                                        +    Control Data Corporation  
>    Dan Horsfall     +1-612-482-4622    +    4201 Lexington Ave North  
>    Internet   ddh at dash.udev.cdc.com    +    Arden Hills MN 55126 USA  

I hope others ARE interested!

--
Brian Hackworth
Data General Corporation            hackworth at dg-rtp.dg.com
62 T. W. Alexander Drive            ...!mcnc!rti!dg-rtp!hackworth
Research Triangle Park, NC 27709    (919) 248-6143