Comment 22 for bug 336634

Apparently the link referenced in comment #7 goes to an unrelated post these days, probably due to some mailing list management changes. I'm quite sure the following thread was meant instead, after digging around 2007-October full archive to find it:

http://lists.freedesktop.org/archives/xorg/2007-October/028961.html

The most discussion on the subject is at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340904 that tries to explain why cflags need to recursively be pulled in for even Requires.private. I'm not particularly agreeing with that, but I see it is necessary as long as there is no way to specify header-only requirements separately, which in turn might be an overkill and as cflags doesn't really imply any extra dynamic dependencies I can live with it.

I found out this bug bites us hard in Gentoo Linux as well, especially in conjunction with xorg proto packages that only provide headers (as for regular packages we don't separate them into regular and -dev packages as is the case in comment #1). Our packages are all built from source even for users, and build time dependencies are handled separately from runtime dependencies, whereas only build time dependencies can be removed after installing (it involves compiling for users), or not installed at all for the case of prebuilt binary packages. So the current state in vanilla pkg-config-0.23 means we'd have to build-time depend on many xorg proto header-only packages for all gtk+ using packages (for example) because pkg-config --exists gtk+-2.0 pulls in for example renderproto via gtk+-2.0 -> cairo -> xrender -> renderproto (latter two being only Requires.private). A fix for this bug would avoid that, and I will need to include such a patch in Gentoo as well, differing from vanilla similar to Fedora.

Please give some attention to this bug, thank you.

Somewhat unrelated to that, but where does pkg-config version control system reside these days...?