Early adopters of symbol based dependencies needed
Hello,
since the upload of dpkg 1.14.8 to unstable, it's now possible for
library packages to generate "symbols" control files that will be used by
other packages to get more accurate (and less strict) dependencies.
As this is a far reaching change, I'd like some skilled maintainers to try
it out "for real" and help me flesh out some generic guidelines so that when
we start using it on more packages, we do it right from the first time.
The wiki page http://wiki.debian.org/UsingSymbolsFiles will be used to
collect various remarks and prepare some useful documentation that will
be later spread to maintainers through d-d-a (and maybe merged back in
some dpkg manual page).
Integrated documentation
------------------------
The existing documentation is integrated in various dpkg manual pages:
- dpkg-gensymbols(1)
- dpkg-shlibdeps(1)
- deb-symbols(5)
Debhelper support
-----------------
With debhelper 5.0.61, dh_makeshlibs will also call dpkg-gensymbols if it
finds debian/<package>.symbols (or debian/<package>.symbols.<arch>). So
for packages using debhelper, the only thing to do is to drop the right
symbol file(s) at the right place and add build-depends on dpkg-dev (>= 1.14.9)
and debhelper (>= 5.0.61).
Some pre-generated symbols files can be downloaded on
http://qa.debian.org/cgi-bin/mole/seedsymbols/
Beware, those files have been auto-generated and should be verified by the
maintainer (check that the version are correct, I just fixed a bug where
epoch were lost). Adapt the dependency field if needed, verify if
the dependency associated to some symbols have to be bumped (see below),
etc.
Warnings
--------
1/ The symbols files associate a minimum version to each symbol that an
application might be using. By default, that version is calculated as the
first version where the symbol appeared. This is the best approximation
that we can automatically generate. Please note however that the function
might have been extended in backwards-compatible ways which would still
deserve an increment of the minimal required version (for example when new
values are allowed in existing parameters which were previously not
accepted). To detect such problems one must have a good knowledge of the
API of the library.
It would be great to have an exhaustive list of similar cases that
maintainers should be watching for in upstream ChangeLogs.
2/ Watch out if adding support of symbols files break unofficial
architectures (like armel or kfreebsd-i386/amd64). Because the
pre-generated files only take into account the current list of official
architectures, so you might not be aware of some differences in the symbol
set. You can check the build log of your package on unofficial
architectures on http://experimental.debian.net/
(http://experimental.debian.net/build.php?pkg=glibc for example).
Feel free to make suggestions to avoid such breakage when possible. See
also discussions in http://bugs.debian.org/452022 on that topic.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: