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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
