Software installation opinions needed

Dave Sill de5 at de5.ctd.ornl.gov
Fri Sep 21 02:24:45 AEST 1990


In article <ROWE.90Sep20061307 at doc.cme.nist.gov>, rowe at cme.nist.gov (Walter Rowe) writes:
>
>>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.

I agree with your reasons, but my answer was in response to Dan
Horsfall's question about his particular application.  I didn't get
the impression that he was talking about a very large or multi-filed
package.  I surely wouldn't want X or FrameMaker dumped in toto into
/usr/bin.

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

Tell me about it.  But X is a special case, I think.  At least, I
couldn't handle a bunch of similarly large and complex systems.  

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

Good point.  Unfortunately, vendors can't rely upon the availability
of symlinks.

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

Sounds neat, but it won't be a real-world solution for a long time, if
ever.

-- 
Dave Sill (de5 at ornl.gov)		These are my opinions.
Martin Marietta Energy Systems
Workstation Support



More information about the Comp.unix.admin mailing list