On Mon, Dec 03, 2007 at 06:38:20PM +0100, Julien Cristau wrote: > On Mon, Dec 3, 2007 at 17:33:41 +0100, Josselin Mouette wrote: > > Every successful call to pkg-config would fill in a file, let’s say > > debian/pkgconfig.deps, that would in the end contain: > > > > # pkgconfig_file required_version dev_package shared_package > > version > > x11 1.0.2 libx11-dev libx11-6 2:1.0.3-7 > > gtk+2.0 2.8 libgtk2.0-dev libgtk2.0-0 2.12.2-1 > > gconf 2.0 libgconf2-dev libgconf2-4 2.20.1-1 > > (The package version is needed because you need to extract epochs.) > > > > In the end, shlibs generation would be able to generate the correct > > dependency, based on the highest of the three versions: > > 1. the version required by upstream; > > 2. the version required by the build-deps; > > 3. the version generated by the symbols file. > > > > Plus, in this specific case, it would make the build fail because the > > Debian maintainer has forgotten to bump the libx11-dev build-dependency > > to 2:1.0.2, which is deadly useful information. > > Why would you depend on any particular version of libx11-6? The > build-dep on libx11-dev >= 1.0.2 I can understand, but the runtime > dependency has nothing to do with this.
For those of us less familiar with X, could you clarify why you wouldn't want a run-time dependency if the upstream configure.ac says PKG_CHECK_MODULES(FOO, x11 >= 1.0.2)? That is, what might they need at build-time that they wouldn't need at run-time? I like Loïc's idea in general; I know that build-time and run-time dependency versions are conceptually distinct but they're not entirely unrelated either. Raphaël's recent changes to dpkg-gencontrol to simplify dependencies also help by making it straightforward to add an explicit dependency in debian/control without worrying about whether people are going to file bugs due to a duplicated dependency. I wonder if the objections raised to this suggestion could be addressed by making it optional in some way - perhaps either by requiring it to be manually enabled for each library by some kind of shlibs/symbols-like system, or by providing support for libraries to declare themselves exempt from it. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
