Fink:Packaging:pkg-config

This page explains our current best-guess about how to do dependencies on the pkgconfig package.

About pkg-config and .pc files

%p/bin/pkg-config is a tool that packages use to determine flags for compiling against other—usually library—packages. The headers component packages of library packages supply a .pc data file that pkg-config reads.

Some .pc files contain syntaxes that are only compatible with certain newer versions of pkg-config and either cause ./configure errors or silently pass incorrect flags when used with older versions. Therefore we need a way to make sure that the proper version of the pkgconfig package is used. These requirements can change version-to-version in the library package and have nothing to do with the packages that use pkg-config. it's not reasonable to keep altering the BuildDepends:pkgconfig versioning in every package that uses the library.

However, there may be other programs that can read .pc files and that may supply an alternate (and compatible) pkg-config program. Therefore we don't want to over-do dependencies on pkgconfig, since that will lead to a mess if any of those other programs get packaged for fink. They would presumably Conflicts/Replaces:pkconfig, so any Depends:pkgconfig will block a smooth upgrade.

A .pc file is pretty useless without a program to process it and pkg-config is the standard tool other packages use. Therefore it makes sense to have packages with .pc have some sort of dependency on pkgconfig. This situation is similar to -dev packages that need other -dev packages, but where BDO prohibits a Depends. Ideally, packages with .pc that have specific pkgconfig versioning requirements would declare an InheritedBuildDepends on it, since pkgconfig is used at build-time. However, we don't have that field. Should pkgconfig itself become BDO when we implement IBD?

Alternative implementations

pykg-config is a pure-python implementation of pkg-config. Its upstream development seems to have stopped, so it might not have all the latest features of pkgconfig itself. However, pkgconfig has build-time and runtime dependencies on glib2. Two main reasons one might want pkyg-config is to avoid the glib2 dependency tree and to avoid circular dependencies within the glib2 dependency tree itself.

Suggested Best-Practices

THIS SECTION IS OBSOLETE (or at least on hold). pkg-config has been beyond 0.20 for years and no currently supported tree has ever had a version older than that, so we do not need to set runtime dependencies to ensure what doesn't seem possible to be likely to be un-met anyway.

Our best solution for the present is to have any library (or other) package that has a .pc with specific version requirements for pkg-config to declare a versioned Depends on the "pkgconfig" package, and packages with .pc files that can be used with any pkg-config version to have no dependency on pkgconfig.

• .pc file in %p/share/pkgconfig instead of %p/lib/pkgconfig

The share/ location was added to the default search path starting in fink's packaging of pkgconfig-0.20. Older versions of the package only looked in the lib/ location. A package that installs a .pc file in the share/ location should declare a Depends to require a pkgconfig version that looks there.

• *.private field in .pc file

The *.private fields were implemented starting in pkgconfig-0.20. Older versions of the pkg-config program silently ignore these fields could therefore supply a deficient set of flags. A package containing a .pc file that has any .private fields needs to declare a Depends to mandate a pkgconfig version that supports them.