Path: utzoo!attcan!uunet!midway!ncar!asuvax!cs.utexas.edu!samsung!munnari.oz.au!mel.dit.csiro.au!yarra!bohra!als From: als@bohra.cpg.oz (Anthony Shipman) Newsgroups: comp.unix.admin Subject: Re: Software installation opinions needed Message-ID: <617@bohra.cpg.oz> Date: 20 Sep 90 03:51:48 GMT References: <25908@shamash.cdc.com> <1990Sep19.125944.6489@cs.utk.edu> Organization: Computer Power Group, Melb, Australia Lines: 57 In article <1990Sep19.125944.6489@cs.utk.edu>, de5@de5.ctd.ornl.gov (Dave Sill) writes: > [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? ................. > 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@bohra.cpg.oz.au Computer Power Group 9th Flr, 616 St. Kilda Rd., St. Kilda, Melbourne, Australia D