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