Re: Injecting versions of build-deps in the deps
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
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.