ldconfig & hardcoded /usr/lib path

[Zdenek Kabelac <kabi@informatics.muni.cz>]

Hello

Few months ago I filled bug report that I don't like the current policy
of ldconfig which is searching  /lib & /usr/lib exclusively no matter
what is the order in /etc/ld.so.conf however maintainer closed this bug
(saying that this bug has been fixed)

Before I'll reopen this bug I'd like to know few things.

I could agree with the forcing usage of /lib, but I don't like
/usr/lib to be forced this way as this is effectivelly eliminating 
the usage of /usr/local/lib directory where I'm sometimes holding
newer version of some libraries or some experimental ones.

I'm also using this method to share /usr between different computers with
different graphics cards (e.g. Matrox, GeForce, non-accelerated)
With the current forced usage of /usr/lib path I could not easily
place the preffered libGL.so in the library search path before the Mesa
libGL from /usr/lib is taken (when the ldconfig respect ld.so.conf
this is very easy)

My current solution is to modify ldconfig binary and replace /usr/lib
to different string however I'm considering this as the solution 
which I really don't like. (As I had to watch for each new update of glibc)

The approach to use LD_LIBRARY_PATH is not acceptable as this way
I would force many user to create various scripts detectecting
from where and which library they should should use on the system they
are currently log on.

Also using unshared /usr is not the solution I would preffer.

So I would like to know if the /usr/lib will never change and it will
stay in ldconfig forever (in this case I would love to see at least some
trigger in dpkg config so I could run some script every time
some package has been upgraded.

Or should I bother glibc authors or Debian glibc maintainer ??

And also is there some explanation available why the glibc mainainers
are forcing the usage of /usr/lib now (because this was not true
half year ago)


bye


-- 
             There are three types of people in the world:
               those who can count, and those who can't.
  Zdenek Kabelac  http://i.am/kabi/ kabi@i.am {debian.org; fi.muni.cz}