Re: Must a source package's shared libraries always be spit into separate binary packages?
On Mon, Feb 19, 2007 at 12:48:21PM -0800, Steve Langasek wrote:
> On Mon, Feb 19, 2007 at 02:10:06PM -0000, Paul Cager wrote:
> > On Mon, February 19, 2007 1:38 pm, Sam Morris wrote:
> > > I am packaging the nemiver debugger, which has a new version that has
> > > split some of its functionality into a libnemiver-common library. The
> > > library is probably not very useful without nemiver itself being
> > > installed.
>
> > > Is it ok to avoid splitting out a separate libnemiver-common0 package, and
> > > instead ship the library file in the nemiver binary package?
>
> > I believe in this case it is OK to keep the library within the main binary
> > package. You'll need to place the SOs in /usr/lib/$PACKAGE, of course.
>
> 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?
Justin
Reply to: