Re: Must a source package's shared libraries always be spit into separate binary packages?
Justin Pryzby <justinpryzby@users.sourceforge.net> writes:
> On Mon, Feb 19, 2007 at 12:48:21PM -0800, Steve Langasek wrote:
>> No, you should *not* put libraries into subdirectories of /usr/lib
>> unnecessarily.
> Policy prefers it for this case:
> 10.2:
> | 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.[57]
> Is there a better way than using rpath?
Yes, installing the libraries in /usr/lib.
The policy wording is really aimed at libraries that are very much not
public -- they don't have an SONAME, they're dlopened instead of linked
against, that sort of thing. If you *can* just build the library as a
regular public shared library in /usr/lib and the program links to it like
normal, it's better to do just do that. The transition issues aren't
difficult when the binaries all come from the same source package, and it
saves a lot of headaches.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: