Summary

The goal is to improve dpkg-shlibdeps so that it generates the minimal dependency required to make the application work instead of blindly using the dependency provided by the shlibs file.

Rationale

In many cases, the dependency generated is too strict as the application doesn't necessarily use the newly-added symbols which justify the dependency bump in the shlibs file. This has many consequences, it can block the propagation of a package in testing waiting for the new version of the library while it would work perfectly fine with the version in testing. The same could even be true between unstable and stable.

Use Cases

Design

Summary

The library packages should provide a new file <package>.symbols along the traditional <package>.shlibs. This file indicates (in theory) for each symbol in which version of the library it got introduced in its current functionality. However since we're not going to do historical research to find the right version, we can use whatever first version we want. In general, it probably makes sense to initiate that file with the symbols coming from the stable version of the library (when the soname hasn't changed and no symbol gained functionality.).

dpkg-shlibdeps will then be modified to extract the list of symbols used by each application and will identify the first version of the library that provides all required symbols.

Storage of the symbols file

The format of the symbols file is the following:

<soname> <main dependency template>
[| <alternative dependency template>]
[ as many alternative dependency templates as needed ]
    <symbol> <first-version>[ <id of dependency template>]
    [ as many symbols as needed ]

A dependency template is a full dependency that might integrate "#MINVER#". This place-holder is then replaced by the appropriate "(>= <min-version>)" when the real dependency is generated. The minimal version is generated by finding the biggest <first-version> out of all the symbols used by the application that are affected to this dependency template. Note that #MINVER# can be empty if the application doesn't use any symbols from a library that it's still linked with.

If a symbol has no explicit <id of dependency template>, then it's supposed to be affected to the main dependency template (id=0). Otherwise the number refers to the <n>'th alternative dependency template.

The file is distributed as part of dpkg's control file in /var/lib/dpkg/info exactly like the current shlibs file.

However we need to keep a copy of that file from one version to the next since it's of no interest if we generate it from scratch each time (listing thus always a dependency on the last version of the library). It would seem logical to store them in the source package itself.

Implementation Plan

Implementation

Outstanding Issues

Possible extensions

Alternative

Guillem Jover has worked on another solution which would work only for libraries providing versioned symbols. dpkg-shlibdeps would extract the version from all symbols used and use that as a base to compute the minimal dependency. The maintainer still has to supply a mapping between "version of symbols" and "version of package".


CategorySpec