rfc: A guide for packaging library udebs
Hello,
While packaging some libraries needed for the graphical installer, I
made some experiences which I would like to share with others. I wrote
a proposal for a packaging guide for library udebs, and would like
some people who perhaps have a deeper inside into library and module
packaging, to review and comment it.
Sebastian
--
PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E F6DB 97E0 3309 9FD6 E3E6
DRAFT+++DRAFT+++DRAFT+++DRAFT+++DRAFT+++DRAFT+++DRAFT+++DRAFT+++DRAFT
Modules that provide libraries
==============================
When packaging library modules some extra care must be taken. This
document provides some basic info on this matter.
Before reading this, it is good to read all other documentation of the
installer project. The library packaging guide from Junichi Uekawa [1]
provides general library packaging practics. It is good to have it
read as well.
Naming
------
Library modules should be named like their deb counterparts, with the
string "-udeb" added after it. For example libc6 will have a
libc6-udeb counterpart and libglib2.0-0 becomes libglib2.0-0-udeb. It
is important to include the soname number in the module name, because
an ABI change of the library will break all modules that depend on
that library and breaks net installs until the dependant modules are
rebuild.
Dependancies
------------
The normal way for a debian package to find out its dependancies is
the shlibs system. Each library installed provides a shlibs file that
states the package which provides this library. This does not work to
figure out the dependancies for installer modules, since the shlibs
files will point to the deb packages providing the library in
question, not the installer module providing it.
To be able to use dh_shlibdeps anyway each library module should add a
"Provides:" line, providing the name of the corresponding deb package
of the library. I.e. libc6-udeb should provide libc6.
Content
-------
The module must content the library itself of course and a symlink
which is named like the SONAME of the library pointing to the
library. The development link as well as libtools .la files are not
needed. If a library comes with modules or data (stored in /usr/share)
it is a good idea to examine, if all of it is necessary and if not, if
it can be removed somehow.
Changing compile options
------------------------
Sometimes it can be necessary to change the compile options for the
module library and so break binary compatibility. Not all changes in
the compile options cause an ABI change, using different -O flags for
example is harmless.
A change of the ABI was necessary for libdirectfb for instance,
because the library of the deb package was compiled with SDL and X
support which would have bloated the installer unnecessarily.
When binary compatibility breaks the soname of the library must be
changed to reflect this situation. As a recommendation the string
"udeb" should be inserted into the soname. Changing the soname can be
easy, if the library is built by libtool and uses autoconf. Refer to
the libtool manual [2] and the autoconf manual [3].
It is not enough to just package the new library into an installer
module. If another module contains programs that link with this
library, this library must be present on the build system.
Since modules should not be installed on normal systems there is need
for a deb package providing this library as well as the necessary
devekopment link. The package should be named libfoo-udeb-dev and
declare a dependancy on libfoo-dev. The only files libfoo-udeb-dev
should provide is the ABI-changed library and the necessary
symlinks. Since the development link is identically to the development
link in libfoo-dev, the library and the links should be installed in a
subdirectory of /usr/lib, e.g. /usr/lib/libfoo-udeb.
If now a program for the installer should link with the ABI-changed
library, the linker must be provided with the "-L/usr/lib/libfoo-udeb"
option, to tell him, where to search for the development link for
libfoo first. This procedure should be documented in the README.Debian
file for libfoo-udeb-dev.
To get everything handled correctly by the shlibs system some minor
tweaking has to be done. To get correct dependancies for installer
modules depending on libfoo-udeb, provide the libfoo-udeb-dev package
with a shlibs file that points to the libfoo-udeb package. For
libdirectfb-udeb-dev the shlibs file contains:
libdirectfb-0.9-udeb 16 libdirectfb-0.9-16-udeb
There is only one problem lasting. If there is an installer module
libbar-udeb depending on libfoo-udeb, that itself also has a
libbar-udeb-dev because of binary incompatibilities, libbar-udeb-dev
will be dependant on libfoo-udeb, which is a installer module and must
not be installed on the build system. To tackle this problem each
udeb-dev should provide the corresponding udeb package,
i.e. libdirectfb-udeb-dev should have a
Provides: libdirectfb-0.9-16-udeb
line.
References
----------
[1] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
[2] http://www.gnu.org/software/libtool/manual.html
[3] http://www.gnu.org/manual/autoconf-2.57/autoconf.html
Reply to: