Kurt Roeckx <k...@roeckx.be> writes:
> On Sun, Jun 21, 2009 at 09:43:16PM +0200, Christian Holm Christensen wrote:
>> This could be very bad for the root-system package set. ROOT has
>> libraries named like libMatrix, libPostscript, libPhysics, libMath,
>> and so on - i.e., very general names. For that reason I moved all
>> the packages into the subdirectory /usr/lib/root to not cause
>> possible conflicts. To make this work seamlessly for both the
>> root-system binaries and user code linked against the libraries, I
>> dump a file in /etc/ld.so.conf.d/.
>> For the root-system binaries, there is of course the option to link
>> with RPATH set. However, I believe that the Policy actually forbids
>> this.
> I see no reason why policy should forbid rpath's for that case. What
> we don't want is an rpath for "/usr/lib". But an rpath for
> "/usr/lib/root" would be the right thing to do for libraries/binaries
> from the root system.
Currently, I don't think Policy says anything about RPATH. It does say:
Shared object files (often `.so' files) that are not public
libraries, that is, they are not meant to be linked to by third
party executables (binaries of other packages), should be installed
in subdirectories of the `/usr/lib' directory. Such files are
exempt from the rules that govern ordinary shared libraries, except
that they must not be installed executable and should be
stripped.[5]
Perhaps that's not quite the definition of "not public" we want?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
