On Wed, 2008-04-16 at 09:33 +0200, Goswin von Brederlow wrote: > Tollef Fog Heen <[EMAIL PROTECTED]> writes: > > > > That depends on the library you are linking against. I, as an library > > author is free to say «the only supported way to use my gargleblaster > > library is through the I_CAN_HAS_GARGELBLASTER autoconf macro» (which > > then proceeds to set GARGLEBLASTER_CFLAGS and GARGLEBLASTER_LIBS by > > using pkg-config). If I do that, pkg-config is effectively part of > > the API. > > I would go one step further. Imho libraries with *.pc files should say > "the only supported way to use this lib is by using pkg-config".
No - because not all libraries restrict support to only pkg-config and there is no good reason to force an option to become a requirement. Just because a .pc file exists, does not mean it is the only supported method - it can be, but it does not have to be. *IF* .pc is the only supported method, then pkg-config is part of the API as above and the -dev dependency is justifiable. However, IMHO, the onus is on the source package to ensure that /usr/bin/pkg-config is available if the source package upstream requires it. > And > as such the *-dev package should depend on pkg-config as that is the > only proper way to use the package. What I'm saying is that the > library should make it a requirement and therefore depends which is > not the same as saying it has to be. It just should imho. Why? The presence of a .pc file is *not* an indicator that pkg-config is essential for that library or -dev, it can be optional. Some libraries may only support pkg-config, others have the option to package a .pc file for those who want it but let other users handle the relevant data directly. Indeed, handling the data separately can be a useful way of removing unwanted dependencies in the final application. The package that *must* depend on pkg-config (build-depend) is the package that runs a ./configure script expecting /usr/bin/pkg-config to exist and without any fallback code if it does not exist. > > | Putting pkg-config on Recommends of Suggests of every -dev packages > > | that has a .pc file, you could as well put it into built-essential > > | dependency. > > How would a Recommends or Suggests even help? Sure, users would get > the pkg-config installed. But buildds don't, right? So sources would > still FTBFS and would have to Build-Depend on pkg-config even if they > only call some autoconf macro from the *-dev package. What about these clauses as a Policy amendment? 1. If a library *only supports the retrieval of FOO_LIBS and / or FOO_CFLAGS by the use of pkg-config*, pkg-config becomes part of the API of that library and the -dev package of that library must depend on pkg-config. The mere presence of a .pc file in the -dev package of the library does *not* mean that only pkg-config is supported. e.g. where a library requires the use of an m4 macro that involves calling pkg-config, this would require the -dev package to depend on pkg-config but if a library provides a .pc file but also supports alternative method(s), the -dev package does not need to depend on pkg-config. 2. If a source package uses libraries that package a .pc but where all the libraries also support other methods of obtaining the relevant data, and the source package requires the use of pkg-config despite those other methods being available, then that choice by the source package upstream must result in a Build-Depends on pkg-config in the source package. Is that suitable as a Policy clause? (probably needs a few tweaks for clarity and examples in clause 1). It may well cause a few packages to depend or build-depend on pkg-config even though another dependency also requires it but duplication of dependencies is not a problem. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
