Re: Injecting versions of build-deps in the deps

[Loïc Minier <lool@dooz.org>]

On Sun, Dec 02, 2007, Mike Hommey wrote:
> I think there is a problem using build dependencies for that purpose:
> There are dozens of reasons why you want to build-depend on libfoo-dev
> >= version that do NOT involve working around bugs in the library at
> runtime. There are so many that it would just pollute a lot of
> dependencies for a few interesting cases, and would sadly end up going
> in the opposite way we are currently heading for with the addition of
> dpkg-gensymbols.

 First, I see this solution as a complement to dpkg-gensymbols when
 symbols are not at the proper granularity to inject deps.

 Yes, in some cases build-deps are bumped for -dev features which are
 not connected to the runtime lib -- shlibs are bumped very often for a
 very small part of the ABI and symbols have a similar problem for ABI
 which can't be expressed by matters of symbols.

 Consider a library providing parsing for "sin()" and "cos()" via
 "result_t parse(const char *)".  It gains support for "tan()" in a new
 version.  If you want to make sure that anything checking at buildtime
 for "tan()" gets it at runtime, you need to inject a very high version
 via shlibs or symbols deps all the time, and all libs get a very high
 dep -- even if they only use "sin()".

> Now, the thing is you can pretty much already do some kind of trick to
> do what you want, with shlibs.local. The only problem with shlibs.local
> is that is forces to use the shlibs in this file and only these, so if
> the package's shlibs tell to depend on a newer version, it won't be
> taken into account.

 Of course, you can argue that the packages should maintain dependencies
 on such ABI manually, but in the case of e.g. Gtk+, I don't expect to
 require 1000 packages to maintain a proper dep on libgtk2.0-0 with
 basically the same version as the build-dep.

 Many upstreams already check for a particular version of a build-dep in
 their configure.ac or whatever; this usually translates in a build-dep
 with a similar version in debian/control.  That's why I propose to use
 this data for runtime as well as it often represents what upstream
 needs at build time and runtime.
   And even if the build-dep was bumped for some other reason, I think
 it doesn't hurt much.

-- 
Loïc Minier