Fink:Packaging:pkg-config indirect deps

THIS PAGE IS OBSOLETE (or at least on hold). The new pkg-config 0.20 does appear to be compatible with the previous functionality, so we do not need to make any changes or do large-scale testing at this time.

pkg-config feature change

In order to upgrade pkgconfig beyond v0.17.2, we need to stop building it with --enable-indirect-deps. That flag causes the pkg-config program to recurse down the Requires field of .pc files in response to --libs and other commands. Without it, only flags from the specific module(s) requested are returned.

In old versions, that behavior was the default; in recent versions, it was optional. We enabled it in order to maintain the existing behavior at the time. In new versions, the flag is broken and upstream does not appear eager to fix it. The new versions implement new fields in the .pc file, so we will have to upgrade pkgconfig soon in order to support packages that use this new syntax.

As a result of dropping --enable-indirect-deps, we need to test all packages that use pkg-config to make sure they still build. This needs to be done "bottom-up" by dependency and linkage. For an example, quux links to libbar via pkg-config and libbar links to libfoo via pkg-config. We need to test-build libbar first, and then test-build quux using the libbar built with the new pkg-config.

The result of this configuration change will be fewer -I and -l flags; this will never require adding (Build)Depends. However, this may reveal that some packages having deficient compiler flags. For example, if quux directly accesses symbols from libfoo but the author did not include libfoo when determining the flags to use when compiling quux, quux will need to be patched to include libfoo. This is as simple as finding the pkg-config commands that handle libbar and adding libfoo to them (usually in the ./configure script, occasionally in the actual Makefile or Makefile.in. These changes do not require increasing the revision: they do not change the binary , and are even safe to use with the old-behavior pkg-config (they merely reinforce the old behavior).

Technically, we will need to increase revisions and use versioned dependencies for the new pkg-config because the results of pkg-config are -l flags that affect the binary of the packages that use them. We also may need to use verisoned dependencies on all packages that link against these packages (and recursively). The linker flags propagate up the dependency chain via .la and other mechanisms that hard-code the flags for all dependencies, not just via .pc files, which are not hard-coded recursively. However, we do not need to force dist-upgrade or use other mechanisms to force the user to upgrade his whole system at once as we will with the C++ ABI change. If he upgrades libbar, he can still use the quux that was built with the old libbar.

In the long run, this may mean we can remove some dependencies from these packages. For example, if quux doesn't directly access things in libfoo, we would no longer need to list libfoo at all for quux. Because 'pkg-config --libs libbar' would stop passing -lfoo to quux, libfoo is no longer a BuildDepends or Depends of quux. As a bonus, if libbar is ever rewritten to use libfoofoo instead of libfoo, we don't need to adjust the dependencies of all packages that use libbar.