On Mon, 29 Apr 2002, Thomas Dodd wrote:
>
> So the package needs to drop a file in /etc/profile.d
> that sets the executable path to /opt/foo/bin
> and man will aututomatically add /opt/foo/man
> to the MANPATH. It will also look for /opt/foo/bin/man
> if you don't want seperate bin and man dirs for each package.
>
> I losty the exact layout you wanted to use, but I think these
> options should do what you need.
>
I agree, provided that you have the PATH included
all applications bin directories there, but that's
unfortunately the weak point too because you don't
have PATH populated with all software you have insalled.
As you build a servers of your own or work on some that
someone else has built you may find that there are few
options how to set up software. Some styles are simple,
some not but work better when you have lot of software.
Some of the ways to work out environment for /opt
applications are
a) You add PATH, MANPATH, LD_LIBRARY_PATH etc to all
users environment from profile or login scripts
- Very straightforward to implement, but pollutes
environment for the all users ie. hard to keep
applications environments separate ... and does
not scale well on large environments, requires
definitions for each shell supported separately.
Works nice environments with not too much different
aged applications. As Linux matures more you will
see more need to support old aplications too.
b) You create and maintain shell function or aliases
that user has to enter some specified command
to 'import' (source) the proper environment before
using application.
- Takes some effort to set up, good applications
separation -- scales well, but needs quite a bit
work maintaining all the functions and aliases
per each shell which then include desired
environment for the user.
Works relatively well where admins do know shell
script programming, otherwise it's a pain.
c) You set up link- and/or shellscript farm to /opt/bin
which is only /opt entry included in PATH variable.
When user references the applicatinon the shell script,
is invoked from /opt/bin which then sets the environment
before launching the application from /opt/application/bin.
- scales well, takes some less effort to maintain than
b), does not pollute user environment like a) and
application environment separation works quite well.
The bad point here is that if the application is
formed from large number of small executables, you
need a wrapper around each.
Works quite well once the startup shell scripts have
been created by someone understanding the workings
of the applications -- a consultant or in-house
admin, or the like.
Which of the a) is propably most commonly used.
The b) and c) are commonly used in large up to supercomputer
class environments, a) does not scale well and will lead to very
hard to maintain and debug system if problems arise subtly by
the time.
With c) individual /opt/*/man entries usually need to be
added to MANPATH.
One very important thing that I have learned past years,
"One size fits for all" does not work for all for all
and it's very good to have options how to set up software.
IMO, the man.config.d and MANPATH globbing serves b) and
c) very well :)
HTH,
:-) riku
--
[ This .signature intentionally left blank ]
_______________________________________________
Redhat-devel-list mailing list
Redhat-devel-list@redhat.com
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
