Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

General Question on App Installation

1 view
Skip to first unread message

as...@lehigh.edu

unread,
Sep 6, 1996, 3:00:00 AM9/6/96
to

Hi there,

I have been recently put in a sys admin position and I have little
experience. One of the things that I have been thinking about lately
is the proper way of adding new applications to a file server. The
universal UNIX method is to stuff everything into /usr/local (or
something like that) where it is not possible to cleanly remove an
applications once it has been installed. So, I am now thinking of
putting each application (e.g. emacs, gcc, gdb, gnu file utils, etc)
into a separate subdirectory under /usr/local (actually /export/local
but that's an unrelated issue). This is against the better judgement
of some of the seasoned sys admins that I know of. Has anyone actually
tried this? I realize that PATH and MANPATH will be long but the idea
of having each installed application as a distinct package is soooo
neat. I can have multiple versions without interfering with each
other, I can uninstall, I can seletively export applicationss.... BTW,
having the env vars the following way makes them look a little more
acceptable too:

PATH=\
/export/local/emacs/bin:\
/export/local/gcc/bin:\
/export/local/tex:\
...

Again, has anyone tried this method? Thanks for all help in advance.

Matthew Archibald

unread,
Sep 11, 1996, 3:00:00 AM9/11/96
to


Ahh... If I only had a dime for every 'seasoned sys admin..'
who continued to think that putting everything in ~/local
was a good way to do busuiness...

If you want to maintain a clean environment and limit your
PATH, MANPATH etc... it is pretty simple to install your
applications in seperate sub-dirs as long as you:

- Create a /usr/local/local-bin
- Put a startup scriptlet for each app into this directory
which holds the neccesary env and path settings approprate
to the app being executed:

- Create a startup script called emacs (hack here yours should
do some error checking etc...):

#!/bin/sh
apppath=/usr/local/emacs,vX.x
appbin=/usr/local/emacs,vX.x/bin
MANPATH=$MANPATH:/usr/local/emacs,vX.x/man
export apppath appbin MANPATH

if [ -x "$appbin/emacs" ]; then
exec $0 "$@"
else
echo "Not going to happen man.... Not there..."
fi

- Add the single path '/usr/local/local-bin' to your
users startup files as appropriate to the shell used

- If you updated versions you create a shell with the new version
path, mv the old to emacs.old, mv the new to emacs and your
off. (links work just as well for version control)

If you had : emacs,v1.0 & emacs,v2.0
You could: ln -s emacs,v1.0 emacs
Then swap later:
mv emacs emacs.last;ln -s emacs,v2.0 emacs;rm emacs.last


Matthew Archibald
Sun Professional Services
Sun Microsystems


Dan Norris

unread,
Sep 11, 1996, 3:00:00 AM9/11/96
to

For installing /usr/local apps, I use a scheme that has become known here
at UIUC as 'encap'. In short what happens is that you install each
application in its own directory under /usr/local/encap. For instance
the gcc distribution is in /usr/local/encap/gcc-2.7.2/ and the actual gcc
binary is in /usr/local/encap/gcc-2.7.2/bin/gcc. Then we use a really
cool perl script to
make symlinks from each package into /usr/local/bin, /usr/local/lib,
/usr/local/man, etc. Then our users only have to put /usr/local/bin in
their path and /usr/local/man in their manpath. The best part is that
upgrading a package is easy since you can easily locate every file
associated with that package.

Even better is that you can still keep the old version around by making
an encap.exclude file in the /usr/local/encap/<app-name> directory and
encap won't make symlinks for the directories you put in that file. It's
the coolest thing since ethernet!

Dan
--
Dan Norris Computer Science, University of Illinois
d-n...@uiuc.edu http://www.uiuc.edu/ph/www/d-norri/
HP Special Project http://www.uiuc.edu/ccso/workstation_grp/hp_project/

0 new messages