Hi Alfonso, Alfonso Ruzafa wrote:
> Hi mentors. Hope you can help me with this. > > I have an Autotools project (named libfoo) with 3 main directories: lib for > the library source code, include for the header files and src for the > command line tool source code to deal with the library. A typical package indeed! Okay, I’m imagining "curl". > I using dh_make using Library creation mode. Then I modify debian/control > file to tune the packages. The package blocks are: > > Source: libfoo (for source code) > Package: libfoo0 (for .so file) > Package: libfoo0-dev (for .a .h files) > Package: foo (for binary file) This is a typical split for a Debian library package. Reasons: libfoo0 should never need to be installed by a user explicitly, except to support third-party programs using your library. The libfoo0 package should be small, so it can be used by other packages in a variety of situations. The soname is included in the package name because (especially during an upgrade) different packages may use ABI-incompatible versions of the library. After an ABI change, it _must_ be possible to have both versions of this package installed at the same time. See policy §8.1: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime Most users would not need libfoo-dev to be installed. Personally, I think supporting multiple development library versions (including the soname in the package name) is overkill, but that’s your choice to make. If the libfoo-dev is _very_ small and feels silly as a separate package, you can include its files in libfoo0 and make that Provides: libfoo-dev, but what does this win you? The foo program is what many users install directly. It should not contribute to the size of libfoo0 (that would be a waste for users of other programs that use libfoo0), and it should not have the soname in its package name (that would make upgrading it obnoxious). If your library is not intended to be used by other programs --- perhaps it does not have a stable API --- then it might make sense to just use one foo package and not ship the files needed to develop with the library. In this case, it might be good to link foo to a static version of the library to avoid confusion, or if the foo package actually provides many binaries using that library, to install the shared library to /usr/lib/foo/ so people are not tempted to use it. > First question: It's good idea to merge library packages with single > packages? Must I use a separate package build structure? Shared libraries for Debian generally must use multiple binary packages. See Debian policy §8: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html > Then, when I run debmake my packages are built well. The second issue is > when I added the packages to a repository using reprepro: the libfoo* files > are included correctly in pool/main/libf but the foo package is also copied > in pool/main/libf. Package pools are organized by source package name. No problem here. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
