Bug#555982: debian-policy: RPATH in binaries and shared libraries
Matt Taggart
This request concerns a particular problem, but I think maybe the answers
might be generic and help with policy.
I maintain a package that runs afoul of the
'binary-or-shlib-defines-rpath'
lintian check, which is currently being discussed in #555982 for addition
to policy.
My package, fossology, uses plugin libraries provided by libextractor in
/usr/lib/libextractor. Currently I have a bug regarding the loading of
those libraries
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531864
A proposed fix is to use rpath so fossology can find the plugins. But if I
do that, then I get the lintian error.
Assuming the libextractor authors wanted those plugins to be public, how
are package maintainers supposed to solve this? Keeping the 112
libextractor libraries in their own subdir seems like a good idea.
Maybe libextractor could drop a path in /etc/ld.so.conf.d/?
Is there some way to solve this so that applications using
/usr/lib/libextractor.so can automatically find the stuff they need in
/usr/lib/libextractor/?
Hopefully answers to these questions can solve the fossology problem _and_
be used to improve the proposed policy text.
Thanks,
--
Matt Taggart
tag...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Kurt Roeckx
> Hi debian-policy,
>
> This request concerns a particular problem, but I think maybe the answers
> might be generic and help with policy.
>
> I maintain a package that runs afoul of the
>
> 'binary-or-shlib-defines-rpath'
>
> lintian check, which is currently being discussed in #555982 for addition
> to policy.
>
> My package, fossology, uses plugin libraries provided by libextractor in
> /usr/lib/libextractor. Currently I have a bug regarding the loading of
> those libraries
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531864
Since libextractor is a library, and it has plugins, I would
assume that the *library* would load those plugins, and that
they're for internal use only, and that maybe there might
be some API to tell which plugins to load. Atleast that's the
most common reason to put libraries in a subdir. And taking
a quick look at the library seems to suggest this is the case.
So /usr/lib/libextractor.so.1 should either set up an rpath
for /usr/lib/libextractor/ or tell the full path to the dynamic
loader when it tries to load it's plugins.
If they weren't plugins you load dynamicly, but something you link
too, I have mixed feelings about using an rpath. I think in the
general case those libraries should probably be in /usr/lib/
instead. It might make sense to put them in a seperate dir
to avoid namespace issues. But at some point you might end up
trying to link to 2 libraries with the same name and you don't
know which one to link to / load.
Kurt
Steve Langasek
> So /usr/lib/libextractor.so.1 should either set up an rpath
> for /usr/lib/libextractor/ or tell the full path to the dynamic
> loader when it tries to load it's plugins.
Preferably the latter; I don't see the point in using rpath for something
other than shared library linking, and it just gets you a complimentary
lintian error, so... (Also, doing this via rpath will, infinitesimally,
slow down the *actual* shared library lookups at startup time.)
> If they weren't plugins you load dynamicly, but something you link
> too, I have mixed feelings about using an rpath.
I don't... in that case they should be in /usr/lib. :)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org