[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Injecting versions of build-deps in the deps


 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

 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

 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

 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: