Use of pkg-config

Richard Purdie richard.purdie at
Sat Sep 27 15:59:20 CEST 2014

On Sat, 2014-09-27 at 01:40 +0200, Guillem Jover wrote:
> I think this request is actually two different ones, but Richard might
> want to clarify anyway. I'd like to shed some light on an important
> distinction that might not have been clear from the initial mail.
> One thing is for GnuPG projects to provide just a pkg-config .pc file,
> as part of its public API, so that external users of those libraries
> *can* choose to use them instead of the *-config scripts, which would
> not impose any additional dependency on the GnuPG projects themselves.
> This has many advantages as Richard mentioned in the thread. It also
> makes life in Debian's multiarch cross-building world much easier as
> the .pc files can be coinstalled on arch qualified paths, so it does
> not matter that their contents differ per arch. It also guarantees the
> same filename and variables and similar are used in all downstreams, so
> that external projects can depend on those instead of possibly unportable
> distribution specific .pc files. I'd expect this part to be pretty much
> an uncontroversial addition, and I'd like to request for the inclusion
> of such files in the upstream GnuPG projects to be reconsidered, please.
> The other thing would be for the GnuPG projects to *use* themselves
> such .pc files (or other external ones) through pkg-config, and as I
> understand it Richard would also like to see this happen, but this
> seems secondary to me given your concerns about dependencies. And
> although even if still problematic it seems it would be easier to
> be dealt with locally.

Given a choice between nothing and some .pc files to help the situation,
I'd much rather have the .pc files even if the GnuPG projects don't use
them directly themselves.

We (as in Yocto Project/OpenEmbedded) are carrying patches to do this
since the .pc files make our lives much easier than the -config ones and
its worth the pain of carrying them :/. I continue to live in hope that
this subject can be revisited.



More information about the Gnupg-devel mailing list