Bug 473814

Looks right to me.

Hmm ok, but lib/lib64 needs to be handled too.

Slightly making priority higher because
for example currently any packages on dist-f11-python which have "BR: libgsf-devel"
all fails with mock status 30 because "Requires: pkgconfig(gobject-2.0)" cannot be
satisfied.

A few points:

1. There's a typo in Arjan's patch: "share/pkgconfg".

2. Unless you override PKG_CONFIG_LIBDIR, the builtin default directories will always be added. So, you could drop prefixing PKG_CONFIG_PATH with /usr/lib*/pkgconfig. That avoids the multiarch problem. Besides, you definitely don't want to prefix PKG_CONFIG_PATH with the system directories since then you'd pickup stale files.

3. In the case that the package puts a .pc file in both $libdir/pkgconfig and $datadir/pkgconfig which have interdependencies, both directories would need to be in PKG_CONFIG_PATH. Since a noarch .pc file in $datadir can't depend on one in $libdir, I think you could do something like this:

DIR=`dirname ${filename}`
export PKG_CONFIG_PATH="$DIR:$DIR/../../share/pkgconfig"

An attemped Empathy update also failed due to the pkgconfig(gobject-2.0) errors mentioned above by Mamoru Tasaka.

There's prefix to worry about as well as .../lib != .../lib64.

Too pad the pkgconfig won't report where it was installed,
which forces pkconfigdeps.sh to guess how to append the
build directory to existing pkgconfig search paths. What
should be done is to add an option to pkgconfig to
emit the current value for defaulted PKG_CONFIG_PATH
so that the build directory can be quietly appended.

These lines from Arjan's patch are non-portable:

        PKG_CONFIG_PATH="/usr/lib/pkgconfig:/usr/share/pkgconfg:$DIR"
        export PKG_CONFIG_PATH


But that should be a pkgconfig, not an rpm, bugture/featlet RFE imho.

Again, you don't need to worry about the default values since pkg-config will add them unless PKG_CONFIG_LIBDIR is set. Also, the build directory definitely should be _prepended_ so they're picked up first.

Yes I'm known senile and dinna fully comprehend comment #4. 

FWIW, your suggestions were just checked in @rpm5.org. Thanks for the patch.

And I still suggest that pkgconfig should emit its own configuration when
needed, but that's a whole different issue than this bug.

(In reply to comment #8)
> pkgconfig should emit its own configuration when needed

https://bugs.freedesktop.org/show_bug.cgi?id=14975

A pkgconfig.pc for pkgconfig is a dead-on, dirt simple, solution.

Can be done in packaging w/o upstream assistance too.

Should be fixed in rawhide now (rpm-4.6.0-0.rc2.6), based on Dan's suggestion.

Ok I thik we can safely close this now, already fixed in rawhide and doesn't really matter for F10 but the fix is on it's way there too.

It appears that empathy-devel has a Requires of pkgconfig(pkg-config) >= 0.21:

http://koji.fedoraproject.org/koji/rpminfo?rpmID=912264

but nothing appears to satisfy that, causing failures of rebuilds of other packages, e.g. desktop-data-model:

https://koji.fedoraproject.org/koji/taskinfo?taskID=1021990

Is this bug the cause of this problem?

There is btw still a problem with upstream RPM,
only the Provides: got fixed, the REquires: side in the same script needs the exact same treatment.

(In reply to comment #14)
> There is btw still a problem with upstream RPM,
> only the Provides: got fixed, the REquires: side in the same script needs the
> exact same treatment.

Seems to be documented here: bug #476199.

Same treatment given to requires upstream now, not in Fedora yet though.

The pkg-config internal provides issue in bug 476199 is not related.

The requires-half added to rawhide too now.