[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 09:33 +0200, Goswin von Brederlow wrote:
> Tollef Fog Heen <tfheen@err.no> 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
> > 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

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

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

Reply to: