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