Aurelien Jarno wrote:
> Why so? As far as I know LD_LIBRARY_PATH is not defined in a standard
> system, being on Debian, Ubuntu, SuSE or Fedora.
Lots of people set LD_LIBRARY_PATH in ~/.profile on multiuser systems,
as a way of installing libraries privately without having permission to
install them system-wide. For example, on one machine my .profile has:
export LD_LIBRARY_PATH
LD_LIBRARY_PATH=$HOME/opt/gcc-4.4/lib64:$HOME/lib
Of course there is no reason to include /lib there, since the system
search path is used after LD_LIBRARY_PATH. But some people may not
have known that and have assumed a closer analogy to $PATH.
Not sure what a good fix is. It is possible to be clever and search
for particular patterns in /etc/profile etc but I don't see how it
could be possible to be at all exhaustive. So I really think the
right way to fix this is documentation.
Maybe a NEWS.Debian.gz entry about multiarch, the libraries having
moved to /lib/<triplet>, and where to read more would be a good thing.
It could mention that anything hardcoding an assumption that libc lies
in /lib (including LD_LIBRARY_PATH) could cause bumps on the road, and
that if that happens due to a Debian package then it is definitely a
bug we are interested in hearing about. Then apt-listchanges users
would have a chance to forsee problems in their local configuration in
advance.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
