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. 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".
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.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
