On Mon, 2007-03-12 at 06:30 -0600, Richard Megginson wrote:
David Boreham wrote:
>
> Some more info on this:
>
> FDS was designed to install at an arbitrary subdirectory in the
> filesystem.
> rpath only supports absolute paths and paths relative to the current
> working
> directory, not the location of the binary (some platforms have some
> support
> for rpath relative to the main binary location but at the time this
> was last
> looked at seriously, that support was spotty and incomplete).
> And so we have wrappers. They allow a user to add one directory
> to their path and run any FDS command without regard to setting
> LD_LIBRARY_PATH.
>
> To remove the wrappers you'd need to give up something :
> install at a fixed location (and use absolute rpaths); don't give
> users the convenience of running commands without setting
> LD_LIBRARY_PATH themselves; only run on platforms
> that have support for relative-to-binary rpath.
We're using the first option on Fedora. We install all of the libraries
in system locations, so there is no need to set rpath or have wrapper
scripts for the command line programs. The only one in question is
libslapd.so, and we could put that in the system $_libdir, or some other
directory that is "approved" by the FHS.
Yeah, that seems very out of place in $_libdir
We were planning to get rid of
the wrapper scripts sooner or later on Fedora. Does this have to be
sooner? Are the wrapper scripts causing some problem (other than an
aesthetic one)?
Not in particular, but an interesting point was made on the fedora-devel
list: If the 'wrapped' binary forks a child, then that unrelated child
also inherits the environment, which may not be desired.
We require the use of wrapper scripts on almost every other platform,
including RHEL4 - and, AFAIK, on other linux distros that put the NSPR
and NSS bundled with the Mozilla clients in the system _libdir. Fedora
solved this problem by making NSPR and NSS independent of Mozilla.
In Samba4, we 'solved' the similar problems (on a smaller scale) by
including the code statically. I can't claim that's a Superior
solution...
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team
http://samba.org
Samba Developer, Red Hat Inc.
http://redhat.com