On Tue, Dec 01, 2009 at 01:56:20AM -0800, Matt Taggart wrote: > 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
