Software installation opinions needed

[Walter Rowe]

>>>>> On 19 Sep 90 12:59:44 GMT, de5 at de5.ctd.ornl.gov (Dave Sill) said:

Dave> Suggest a default, but allow the installer to either specify an
Dave> alternate when running your installation script, or tell them
Dave> how to edit the script itself.

I agree.  As a system administrator, I get frustrated when I install a
third party package that won't allow me to dictate where it resides.
Frequently, I prefer to install it in /usr/local or in our depot
(which Don Libes mentions in a followup post).  In addition, I don't
care to allocate huge amounts of disk space on "/usr" since that is
not generally a network-shared file system but rather a file system
local to each machine.  Imagine doing 100+ X11R4 "make install"s.

FrameMaker, X windows, all the GNU software, and the Verdix Ada
compiler are great about letting me dictate their place of final
resting.  They modify their internal startup scripts or header files
accordingly when you run the installation.  You do have to modify your
path to access most of them, though you can provide symlinks in for
instance /usr/local/bin which usually is a network-shared file system.

>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) ?

Dave> Probably a good idea.

I don't necessarily agree for a couple reasons.

[1] We have nearly 100 machines on our net served by five central
    servers.  When we upgrade machines, its nice not to have to
    re-install all the third-party software we have.  Ever have to
    install something like X11R4?  Its quite time consuming.

[2] Using symlinks, we can keep all the various third-party packages
    separate, and their self-documenting.  For instance, a symlink in
    /usr/local/lib like "libX11.a -> /depot/X11/lib/libX11.a" lets me
    know right away that this is part of the X11R4 distribution and
    not part of the OpenWindows 2.0 distribution which also contains a
    file by the same name.

>b) Recommend adding a new directory to $path?

Dave> Nah, too much of a hassle, and PATH's are getting too long.

Yeah, I don't go for having to add things to my path.  Users don't
should't have to modify their path each time you get a new package,
and admins should be able to decide where the application really
resides.

As an aside, one option we are looking at here at NIST that would help
solve this exact problem is the SunOS TFS (Translucent File System),
which allows you to mount directories in a stack and still see all the
different files underneath.  You can mount bin directories from
several places onto one common place and users would only ever have to
add the one common bin directory to their path.  If I add a new
application, I add its bin dir to the TFS list and BANG! users have
access to it.  No symlinks, no relocating applications, nothing!

For instance, the X11R4, GNU, and Frame bin dirs can be mounted onto
say /depot/share/bin.  If you add /depot/share/bin to your path, then
you have access to all these applications.  I don't have to move them
their, you don't have to have a long path, and I can add/change mounts
any time and you automagically see the effects without changing your
path ever again.  When X11R5 comes out, I simply change the TFS list
and you have automatically migrated to X11R5.

>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..."

Dave> There are zillions of "Don't do's", but in general, don't create
Dave> or modify anything without notifying the installer.

Definitely!  I don't like to find out too late that your script
overwrote a file that just so happens to have the same name (for
whatever reason) as one I already had.

>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...

Dave> I think this is relevent for comp.unix.admin folks.

This is quite relavant to Unix administration.  I wish more vendors
would ask customers these types of questions before they sent out
products.  I apologize for rambling on as I have, but hopefully other
admins will find this stuff interesting and useful, and perhaps it
will spur innovative ideas of their own.  Are other people using TFS?


wpr
---
Walter P. Rowe                                    ARPA: rowe at cme.nist.gov
System Administrator, Robot Systems Division      UUCP: uunet!cme-durer!rowe
National Institute of Standards and Technology    LIVE: (301) 975-3694