Injecting versions of build-deps in the deps
Hi,
Some packages require running with versions of libraries at least as
high as the versions used during the build. I think we should offer
packagers a system to generate dependencies close to this, but not as
strict. This would complement our current infrastructure nicely,
some of the rationale follows.
In Debian, we have the shlibs system and now the "symbols" system to
inject dependencies when ELF binaries depend on shared libs or symbols
in shared libs.
The shlibs system worked nicely and permits injecting high deps when
the ABI is augmented backwards-compatibly, but this is not enough in
all cases:
Consider libfoo which doesn't change API/ABI, but sees a bug fix,
shlibs aren't bumped as the lib is backwards-compatible. Package
foobar detects the bugged version of libfoo at build time, and
enables/disables a workaround. The shlibs/symbol systems will
neither prevent foobar to build the workaround and run with the new
libfoo, nor to disable the workaround and run with the old libfoo.
The symbols system currently bypasses shlibs and will make sure that
you get a version of a lib providing all ELF symbols that your binaries
need, but like the shlibs system it only sees the ELF level:
Consider libfoo2 which manipulates frozzles and doesn't change
API/ABI at the ELF level, but gains support for a new frozzle.
Package foobar2a needs the new frozzle, package foobar2b doesn't.
The shlibs or symbols systems will either a) inject dependencies on the
new version and hence give overly high dependencies for foobar2b or
b) inject deps on the old version and hence give too loose deps
(requiring the foobar2a to add a manual dependencies to get the new
frozzle).
In general, the shlibs and symbols systems inject dependencies which we
would like as low as possible for each package [1], but the amount of
information in the binaries is insufficient and encourages maintainers
to bump injected dependencies at high levels.
Similar problems exist outside of ELF binaries, such as across Python
packages.
An idea that came up is to use a per-dependent package information
provided by the maintainer such as the build-deps version [2]. It
would require a map from deps to build-deps and could typically be
combined with the existing systems to inject a dependency >=
max(shlibdeps version, bdeps version).
An example would be package foobar3 build-depending on libfoo3 (>=
2.10.2). When built against libfoo3 2.12.0-2 which provides a symbols
file, the resulting binaries need symbols from libfoo3 (>= 2.8.7) (as
the symbols file say), the new system injects a dep on libfoo3 >=
max(2.10.2, 2.8.7) == 2.10.2.
If libfoo3 only provides shlibs and no symbol file and the shlibs
claim a dep on libfoo3 (>= 2.10), the system would inject a dep on
libfoo3 >= max(2.10.2, 2.10) == 2.10.2.
What do you think of such a system? Please share your ideas and
comments!
Thanks to Raphaël Hertzog, Josselin Mouette, Julien Cristau, Aurélien
Jarno, and Julien Blache (and the others I forget) for their arguments
and comments on the topic and similar topics.
[1] to help transitions to testing, or to ease installation of packages
from $next-release without rebuilding, to ease upgrades
[2] it could be a new field, but you would want to use it in the
build-deps anyway; using b-deps is backwards-compatible and the most
likely version we would want to start with
--
Loïc Minier
Reply to: