Path: utzoo!attcan!uunet!cs.utexas.edu!asuvax!ncar!mephisto!mcnc!rti!dg-rtp!dg-rtp.dg.com!hackwort From: hackwort@dg-rtp.dg.com (Brian Hackworth) Newsgroups: comp.unix.admin Subject: Re: Software installation opinions needed Message-ID: <1990Sep19.144819.12179@dg-rtp.dg.com> Date: 19 Sep 90 14:48:19 GMT References: <25908@shamash.cdc.com> Sender: usenet@dg-rtp.dg.com (Usenet Administration) Reply-To: hackwort@dg-rtp.dg.com (Brian Hackworth) Followup-To: comp.unix.admin Organization: Data General Corporation, Research Triangle Park, NC Lines: 166 In article <25908@shamash.cdc.com>, ddh@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/ 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@dash.udev.cdc.com + Arden Hills MN 55126 USA I hope others ARE interested! -- Brian Hackworth Data General Corporation hackworth@dg-rtp.dg.com 62 T. W. Alexander Drive ...!mcnc!rti!dg-rtp!hackworth Research Triangle Park, NC 27709 (919) 248-6143