ddh@hare.cdc.com (dd horsfall x-4622) (09/18/90)
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?
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?
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?
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..."
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)?
( Sidebar: How many of the above directories are local to my site and I
don't know any better? Are any of them specific to certain vendors? Does
the list of "standard" or "conventional" directories vary between
SysV and BSD based systems? )
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 gt0178a@prism.gatech.EDU (BURNS,JIM) (09/19/90)
in article <25908@shamash.cdc.com>, ddh@hare.cdc.com (dd horsfall x-4622) says: [request for guidelines on writing software installation procedures] > 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... I for one would disagree - this is right up the alley of one of the groups you posted to - comp.unix.admin. If others disagree, pls send me a summary. -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
de5@de5.ctd.ornl.gov (Dave Sill) (09/19/90)
[Followup redirected to comp.unix.admin.] In article <25908@shamash.cdc.com>, ddh@hare.cdc.com (dd horsfall x-4622) writes: > >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? Nothing formal, but the UNIX System Administration Handbook (Nemeth, Snyder, & Seebass) has a chart on page 41 that lists a bunch of these. For example: /bin commands needed for minimum system operability /usr/bin executable files /usr/local/bin local software (BSD) executables /usr/new new software that will soon be supported (BSD) /usr/etc where Sun puts things that everyone else puts in /etc >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? Suggest a default, but allow the installer to either specify an alternate when running your installation script, or tell them how to edit the script itself. >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) ? Probably a good idea. >b) Recommend adding a new directory to the $path? Nah, too much of a hassle, and PATH's are getting too long. >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? Why? What good does the redundant link do? >How many of your third-party (i.e., not vendor-supplied) products fall >into the above categories. Which do you prefer? Most seem to take path b), but I find it annoying; not as an administator, but as a user. I'm sick of having to fiddle with .logins, .profiles, and .bashrcs on my various systems every time I install a new commercial product. I don't mind, for example, having to create /usr/frame to install FrameMaker, but why don't they install the `maker' script in /usr/bin rather than force people to cd to /usr/frame and run bin/maker or add /usr/frame/bin to their PATH and create an FMHOME environment variable? >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? I generally like the way DEC installs go, using the utility `setld'. It allows installations from tape/cdrom or disk files, allows installations to be reversed (a *very* nice feature), can produce a list of installed software, etc. Unfortunately, only DEC has it. >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..." There are zillions of "Don't do's", but in general, don't create or modify anything without notifying the installer. >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)? I don't know. >( Sidebar: How many of the above directories are local to my site and I >don't know any better? I've seen tham all before, one place or another, so they aren't site-specific. >Are any of them specific to certain vendors? Even /usr/etc, which Nemeth indicates is Sun-specific, is found on most UNIX systems, it's just that Sun seems to be particularly fond of it. >Does >the list of "standard" or "conventional" directories vary between >SysV and BSD based systems? ) Yes. For example, /usr/new and /usr/old are BSD-only and /usr/lbin is ATT-only. >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... I think this is relevent for comp.unix.admin folks. -- Dave Sill (de5@ornl.gov) These are my opinions. Martin Marietta Energy Systems Workstation Support
bob@pta.oz.au (Bob Vernon) (09/21/90)
In article <25908@shamash.cdc.com> ddh@dash.udev.cdc.com writes: > 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... I beg to differ. This query is perfect for comp.unix.admin and it gives me chance to get some things off my chest. Follow-ups to comp.unix.admin > 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..." Whatever you do, DON'T ever ever, pretty please, don't do it, don't even think about doing either of the following :- (I work as a Pre-sales support engineer for my company, and I am frequently demo-ing third-party packages. This means installing and REMOVING the package and there is nothing that pisses me off more than either of the following two problems). DONT #1 : Do not install any program in a standard directory without giving the installer an option of changing the location. I hate install programs that shove programs in /usr/bin without telling me. On our in-house system third-party programs are always installed in /usr/local/bin and we recommend this for customers as well. It makes life a lot easier when upgrade time comes around. But this is our preference. Many sites would have a different opinion on the best location for 3rd party sw. So the install script should ask the installer "Where do you want to install the program?". It can recommend somewhere if it wants. The same goes for any data files, help files, other programs etc, etc that your programs needs. These should never be installed in /usr/bin or /usr/lib unless the installer approves. The best solution I find, is to create various local sub-directories (eg package/bin package/lib package/help) and set up environment variables to access. I know some people hate environment variables but thats OK. Create a wrapper script during installation that sets up all the environment and adjusts the PATH. This wrapper script is then the only thing that needs to be in the Users default environment. DONT #2: Don't ever mess with my system files. Eg, /etc/rc, /etc/rc.local or god forbid /etc/passwd. If you need a daemon started or some cleanup done at boot time, then create a boot time script, tell me where it is and ask me to add it to rc.local. Or at least tell me what you are about to do and give me a chance to change the filename you are about to munge. And if you must have an entry in /etc/passwd, then tell me the details and ask me to add it. Do NOT assume that your passwd entry will have userid 63 and groupid 37. Don't laugh, I've installed a package like this. When the install failed, I naturally tried it again. By the end of the day the package had 6 passwd entries all clashing with some quite innocent user. RECOMMODATION : Make your install procedure nice and administrator friendly. (This is not the same as user-friendly). Give me the chance to change any install location. Tell me what you are about to do before you do it. Above all, don't stuff up my system without my approval. Bob V! -m------- Robert Vernon DOMAIN: bob@pta.oz.au ---mmm----- Pyramid Technology (Australia) UUCP: pyramid!pta!bob -----mmmmm--- 328 High Street PHONE: +61 2 415 0515 -------mmmmmmm- Chatswood 2067 Australia FAX: +61 2 417 8232
davecb@yunexus.YorkU.CA (David Collier-Brown) (09/21/90)
[Alas, I couldn't send mail to ddh@dash.udev.cdc.com: here's my views] ddh@hare.cdc.com (dd horsfall x-4622) writes: >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? Sure, but its a history, not a standard (:-)). /bin is stuff you need to get up single-user /usr/bin is for multi-user on a V6 or later system /usr/local (or /usr/local/bin if you have a /usr/local/{lib|include|man}) is for local more-or-less trusted tools, post v6/v7 /usr/new (or /usr/local/bin/new, or whatever) is either untrusted and beta-test stuff (in the olden days) or "what we added" (in the newden days) /usr/ucb is the stuff added at the time of release of the University of California, Barkley (they spell it funny (;_)) virtual-memory version of V7/V32 /usr/5bin on Berkleyzoid boxes is sys V stuff added by the vendor /usr/sbin is ...I forget. >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? c) is the least intrusive. >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? Well, for small programs I'd suggest moving/copying to the agreed-upon location from the installation area. For large or complex ones, I'd leave most of the stuff in an agreed- upon location or symlinked to same, and optionally move some small component into people's paths. An unmentioned problem is the ``where did I come from'' problem when the application looks for the place the rest of it lives in. TeX uses environemnt variables, some things leave symlinks in well-known places (/interleaf/4.0 is a symlink to another well-known typesetter) and some leave /etc/whatever.config files around. I recommend the same script that installs, deinstalls and updates versions of the product leave both a symlink somewhere plausible (eg, /usr/local/lib/<product-name>) and copy the minimum number of components to the selected bin directory. This script lives in the installation area, so that when the customer reinstall unix, (s)he can reinstall the program easily. >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? See if you can get the InterLeaf manual for sunos... I don't have one any more. >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..." ... assume that there will be exactly one sucessfull installation. >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)? >( Sidebar: How many of the above directories are local to my site and I >don't know any better? Are any of them specific to certain vendors? Does >the list of "standard" or "conventional" directories vary between >SysV and BSD based systems? ) > >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... You might be surprised: feel free to summarize advice in a posting... > 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 --dave -- David Collier-Brown, | davecb@Nexus.YorkU.CA, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave or just Willowdale, Ontario, | postmaster@{nexus.}yorku.ca CANADA. 416-223-8968 | work phone (416) 736-5257 x 22075