Software installation opinions needed

[Anthony Shipman]

In article <1990Sep19.125944.6489 at cs.utk.edu>, de5 at de5.ctd.ornl.gov (Dave Sill) writes:
> [Followup redirected to comp.unix.admin.]
> 
> In article <25908 at shamash.cdc.com>, ddh at 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?
.................
> 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?

A problem that I always worry about is name collisions. When program names are
abbreviated (often to ridiculous extremes) there is a real chance that somebody
else's program will have the same abbreviation. If they are all installed in
/usr/bin then installing one package will wipe out another.

Installing a package with its own bin directory gets around the problem but
introduces the hassle of Yet Another Path Directory. Even 'maker' is too short
for my liking. What indicates that it is framemaker and not somebody else's
*maker or "makerules" etc?

Call it framemaker or even FrameMaker if that is what it is. If the customer 
thinks the name is too long to type then he/she can use a shell alias or 
equivalent. 

This has the added advantage that when I look through the bin directories I 
know what the programs are. Too many times I have seen this file in a bin
directory with a meaningless string of characters for a name and not known what
package it belongs to.  There's another tip for software vendors. Supply a list
of installed files with each product in *machine readable* form so that I can
search it to find if the file belongs to the product.

This can be summarised as "Minimise the constraints on the customer".

-	Don't constrain me wrt what directory to install into. I might not have 
	the room on that file system.

-	Don't choose my program name abbreviations for me, I probably won't like
	it.

-	Don't constrain me by leaving me ignorant about what the programs I find in
	my bin directories are.

etc. etc.
-- 
Anthony Shipman                               ACSnet: als at bohra.cpg.oz.au
Computer Power Group
9th Flr, 616 St. Kilda Rd.,
St. Kilda, Melbourne, Australia
D