pkg-config "Requires" fields and propagated inputs

[Taylan Ulrich Bayırlı/Kammer]

I would appreciate it if someone helped me wrap my head around this.
Ideally I already got it and the following summary is correct; otherwise
please correct.

Pkg-config files (e.g. lib/pkgconfig/foo.pc for libfoo) may have a
"Requires" and a "Requires.private" field.

If I'm reading pkg-config documentation[0] right, Requires are full
run-time dependencies, meaning if a program uses libfoo which Requires
libbar, the program will also want/have to use libbar's interface; OTOH
Requires.private are "link-time" dependencies, i.e. libfoo dynamically
links to libbar, so libbar needs to exist on the system at run-time, but
a program using libfoo needn't use libbar's interface.

This would mean that Requires should be propagated inputs, and
Requires.private only normal inputs; they needn't be in the profile of
the user who installs libfoo; it's enough that libfoo refers directly to
their path in the store.

However, pkg-config isn't aware of compile-time/run-time dependency
differences; it's considered an error if a Requires.private of libfoo
isn't found, because as far as pkg-config is concerned, it means libfoo
is dysfunctional.  So we *do* need to propagate Requires.private, for
the sake of pkg-config.  (The problem mainly manifests in the form of
./configure scripts claiming libfoo isn't found when it's only libbar
that's missing, because in that case pkg-config returns an error to the
./configure script when inquired about libfoo.)

[0] http://people.freedesktop.org/~dbn/pkg-config-guide.html

P.S.: I'll see if I can write a tool that compares the union of the
Requires[.private] fields of all .pc files in a package to the package's
propagated inputs, so we can detect mismatches automatically.

Taylan