On Wed, 2008-04-16 at 17:23 +0200, Bas Wijnen wrote: > First of all, I skipped a large part of this thread, so I'm sorry if > this has come up before. > > On Wed, Apr 16, 2008 at 03:53:03PM +0100, Neil Williams wrote: > > > And by this definition, it is the package _invoking_ pkg-config that > > > should Build-Depend on it, not the package that happens to ship a .pc > > > file. > > > > I agree with that interpretation and that intention, I'm just not sure > > it covers all eventualities. > > What is missed, I think, is the situation where: > - the library which ships the .pc file also ships a script which calls > pkg-config, called foo-config. > - the library provides this as an option, and lets you use other options > (for example using pkg-config directly) as well. > - the library wants the foo-config option to be opaque, that is, it may > stop using pkg-config in the future, and use some other method to > provide the flags. That is an example of a library including pkg-config into the library API. Changing that behaviour (dropping the script) means a SONAME bump. > According to the suggested definition, if a package using this library > chooses to use foo-config, it doesn't call pkg-config directly (and it > may not call it at all, this depends on the inner workings of > foo-config). During the time that foo-config calls pkg-config, the -dev package containing foo-config must depend on pkg-config. That follows logically from the "you call it, you depend on it" model. > So the package wouldn't need a Build-Depends: on > pkg-config. However, the library doesn't need a Depends: either, > because the package can well be used without pkg-config. Which is where that complexity comes in again - if the package calls foo-config, it must depend on the -dev. If foo-config *as a script* requires pkg-config, the -dev must depend on pkg-config because it is calling it. A simple .pc file doesn't call anything so that does not lead to a dependency on pkg-config for the -dev. If we stick with the idea of "you call it, you depend on it", these situations become a lot clearer. If foo-config changes internally to not call pkg-config anymore, that allows the -dev to drop the pkg-config dependency. What is wrong, therefore, is for the package using foo-config to expect that the -dev continues to provide pkg-config and to then use pkg-config itself for other things *without* a dependency. i.e. a duplicate dependency is the best approach here. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part