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