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