On Wed, 2008-04-16 at 16:12 +0200, Gabor Gombas wrote: > On Wed, Apr 16, 2008 at 11:23:51AM +0100, Neil Williams wrote: > > > 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). > > Wow, that's awfully complicated.
Yes, I realise that. > This is much more straightforward: > > "If a package wants to call /usr/bin/foo during build and fails > to build properly if /usr/bin/foo is not present, then the > package MUST Build-Depend: on some other package providing > /usr/bin/foo". It doesn't account for packages where pkg-config really is part of the API of the library but maybe that is the way it should be. If a library enforces the use of pkg-config, it is still the choice of upstream to use that library or implement a different version - as such, the choice carries a consequence of depending on pkg-config in Build-Depends. I'm not convinced that that is such a penalty but others on -devel wanted a different view so I tried to cover that in the clauses. I was merely trying to reflect other threads in this discussion - I haven't actually got a concrete example of a library that includes pkg-config into the API. There may well be corner cases I don't know about but AFAICT most cases would be met correctly by the simpler expedient of "you use it, you depend on it" as you describe. > 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. -- 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
