Red Hat Bugzilla – Bug 473814
rpm's pkgconfig auto provides is broken (fix included)
Last modified: 2009-02-21 06:25:27 EST
Created attachment 325146 [details]
Description of problem:
the current code in rpm that does the pkgconfig auto provides is bust for the scenario where a package has multiple .pc files, and where some of these depend on a .pc file that is provided by this package.
rpm -q --provides glib2-devel
this should show about 5 pkgconfig provides, but it only shows 1.
The reason is that pkgconfig will refuse to print out the provides if a .pc file has unmet dependencies.
The fix is to make sure that the target pkgconfig directory is part of the PKG_CONFIG_PATH environment variable when calling pkgconfig; as done by the attached patch.
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
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:
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:
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
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:
but nothing appears to satisfy that, causing failures of rebuilds of other packages, e.g. desktop-data-model:
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.