Re: Should -dev packages providing .pc files depend on pkg-config?

[Goswin von Brederlow <goswin-v-b@web.de>]

Gabor Gombas <gombasg@sztaki.hu> writes:

> 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

You are missing the point.

What if the library says "You must call /usr/bin/foo during build"?
The libarry does not use foo, only the user, so no depends?
Or idoes forcing users to use foo make foo part of the API and hence
the library should depend on it?

MfG
        Goswin