[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Must a source package's shared libraries always be spit into separate binary packages?



On Mon, Feb 19, 2007 at 07:36:13PM -0500, Justin Pryzby wrote:
> 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?

"Shared object files that are not public libraries" refers primarily to
*DSOs*, not to libraries that happen to only have one user.

If you are going to insist that these libraries are "private" and should be
kept out of the standard LD_LIBRARY_PATH (even though they're shipped that
way upstream), then yes, use rpath.  Adding the path to /etc/ld.so.conf.d
means that *the libraries aren't private, they just complicate library
lookups and make conflicts harder to spot*.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Reply to: