Re: Autotools (library + binary) to debian packages
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
Reply to: