Re: Must a source package's shared libraries always be spit into separate binary packages?
On (19/02/07 14:37), Sam Morris wrote:
> On Mon, 19 Feb 2007 14:10:06 +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.
>
> Hm, this sounds overly complicated--editing /etc/ld.so.conf in the
> maintainer scripts, etc.
There should not be a need to do this.
> Why shouldn't I just provide a nemiver.shlibs
> file that points dpkg-shlibdeps at the nemiver package?
>
Is the new library linked to by other programs?
If so then you might want to consider a separate package. If not then
stick it in /usr/lib/$PACKAGE out of the way, and make whatever uses it
use it there. That wont always work, but if it doesn't it probably
indicates it should be in /usr/lib and probably a separate package.
It is possible to ship more than one shared lib in a package (see
libgnutls13 for instance). There are a few issues with doing this. One
is that the package has to be named for one of the libraries only. The
other is for versioning. For the above example upstream know what they
are doing, which means that we don't need to worry about backwards
incompatible changes in the secondary libraries. If your upstream
doesn't, or has split the libs to specifically allow them to do this,
then you should think twice about using the shared package, as if the
secondary lib requires a soname bump then you will have more work in the
transition. You will have to fake a new package version in some way to
try and achieve it, and if it happens regularly it will get very ugly.
Also if only a minority of programs are going to link to the secondary
library you can reduce dependencies by splitting it out. This would also
help in any transitions that you have to do.
Thanks,
James
--
James Westby -- GPG Key ID: B577FE13 -- http://jameswestby.net/
seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256
Reply to: