[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

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

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: