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

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



Tollef Fog Heen <tfheen@err.no> writes:

> * Hendrik Sattler 
>
> | Am Samstag 05 April 2008 schrieb Tollef Fog Heen:
> | > Whoever develops software based on libbar will have to have a call to
> | > pkg-config somewhere in their build process so they should depend on
> | > pkg-config.
> | 
> | _If_ they do. Please consider the possibility that an application
> | developer links to libbar without using pkg-config. pkg-config is
> | _not_ part of an API, it is only a tool that _can_ be used, not
> | must.
>
> 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
> then proceeds to set GARGLEBLASTER_CFLAGS and GARGLEBLASTER_LIBS by
> 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". 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.

> | 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.

MfG
        Goswin


Reply to: