Comment 58 for bug 336634

I've read the guide, but the few words about the Requires/Requires.private doesn't help me to understand the usage. (I've understood the behaviour, but I do not see the matching usage).
So what is following is what i imagine of the differences between Requires and Requires.private.

1-
Actually, if a package use the Cflags from Requires.private for the includepath. It means it will use the headers included from Requires.private. As a consequence, it will <<have to>> "use symbols" of the related libs from Requires.private. Which, if they aren't defined at build time (linking) will need to be resolved at runtime. (rpmlint on installed packages will show undefined-non-weak-symbol).
(If you don't agree with this part you will have to give an example).
I don't see how a package could see some interest in linking to gconf while not linking to dbus directly.(if ever dbus headers was used in GConf2-devel which is not the case).
I could imagine source distribution like gentoo could see some interest in having such behaviour to avoid relinking to the new SOVERSION of a library, but it would fall under the dirty hack.

We (as precompiled distribution as a whole) want this case to fail at install time (instead of opening the possibility of missing symbol at runtime).
It could be possible to have exeption, but it is the common case. And we rely the fact that shared libraries are linked at build time with an appropriate SOVERSION.

2-
Then I've wondered if it has something to do with building software from a tree.
The main feature between tree vs installed software are that "private headers" start to be accessible.
So it would have been unappropriate to use Requires.private from gconf-2.0.pc instead of gconf-2.0-uninstalled.pc.
But even in this case, there is a need to link to libs (more than ever actually). And fetching both Cflags and libs is exactly the same behaviour as Requires:). So maybe the Requires line of a given *-(installed).pc can be different than *-(uninstalled).pc, but it still doesn't explain the different usage of Requires.private versus Requires

3-
Now what is misleading (see http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-November/056017.html ) is that as Libs.private is known to do have something to do with static library, some might expect the same with Requires.private. But it is not. (that was the previously patched version of this bug, more or less).

The previous case was more or less rare cases, whereas this is a way more common. When a binary is aimed to be portable on any given GNU/Linux distro it may links against a static version of a library. But such library will only contain symbol of itself, hence there is a need for the static linker to search for its dependency also. Here is what would Requires.private aimed for.
It helps the linker to find symbols needed by a given static library. If only a shared library exist, it stop to the Libs. If it is a static library, then it pick Requires.private in the related .pc file and so on.

Then pkgconfig could look at some environment value to say when both static version and shared version exist which ones to pick. and eventually, which versioned symbol (like libresolv.so.2(GLIBC_2.9) in glibc) need to be picked from the static version, and other (ex: -lGL) from the shared version.

But it would mean pkgconfig --libs package --static would fetch the Requires.privates libs and not the cflags, which is the opposite of what the vannilla pkgconfig do.

@Matthias
As you've said previously, you were reluctant to do the update.
Whatever your current personal thought are; I do think we need a "common decision" to be made, so we can advertise packagers about how to eventually fix things in stable release accurately. (and send the patches upstream as appropriate).

So I'm requesting a topic about "pkgconfig how to deal with Requires.private" to be discussed at friday 20th FESCo.