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