Bug 473814 - rpm's pkgconfig auto provides is broken (fix included)
rpm's pkgconfig auto provides is broken (fix included)
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
10
All Linux
urgent Severity medium
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 459989
  Show dependency treegraph
 
Reported: 2008-11-30 16:34 EST by Arjan van de Ven
Modified: 2009-02-21 06:25 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-21 06:25:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The Fix. (677 bytes, patch)
2008-11-30 16:34 EST, Arjan van de Ven
no flags Details | Diff

  None (edit)
Description Arjan van de Ven 2008-11-30 16:34:47 EST
Created attachment 325146 [details]
The Fix.

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.
Example:
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.
Comment 1 Matthias Clasen 2008-11-30 18:27:30 EST
Looks right to me.
Comment 2 Panu Matilainen 2008-12-01 01:06:07 EST
Hmm ok, but lib/lib64 needs to be handled too.
Comment 3 Mamoru TASAKA 2008-12-01 12:15:34 EST
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.
Comment 4 Dan Nicholson 2008-12-01 14:22:56 EST
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"
Comment 5 Peter Gordon 2008-12-01 14:24:35 EST
An attemped Empathy update also failed due to the pkgconfig(gobject-2.0) errors mentioned above by Mamoru Tasaka.
Comment 6 Jeff Johnson 2008-12-01 14:51:37 EST
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.
Comment 7 Dan Nicholson 2008-12-01 14:56:18 EST
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.
Comment 8 Jeff Johnson 2008-12-01 15:05:54 EST
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.
Comment 9 Ville Skyttä 2008-12-01 15:51:38 EST
(In reply to comment #8)
> pkgconfig should emit its own configuration when needed

https://bugs.freedesktop.org/show_bug.cgi?id=14975
Comment 10 Jeff Johnson 2008-12-01 16:06:59 EST
A pkgconfig.pc for pkgconfig is a dead-on, dirt simple, solution.

Can be done in packaging w/o upstream assistance too.
Comment 11 Panu Matilainen 2008-12-02 11:49:11 EST
Should be fixed in rawhide now (rpm-4.6.0-0.rc2.6), based on Dan's suggestion.
Comment 12 Panu Matilainen 2008-12-20 03:21:07 EST
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.
Comment 13 Alex Lancaster 2008-12-26 04:03:09 EST
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?
Comment 14 Arjan van de Ven 2008-12-26 04:07:04 EST
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.
Comment 15 Alex Lancaster 2008-12-26 04:10:18 EST
(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.
Comment 16 Panu Matilainen 2009-02-05 14:19:44 EST
Same treatment given to requires upstream now, not in Fedora yet though.

The pkg-config internal provides issue in bug 476199 is not related.
Comment 17 Panu Matilainen 2009-02-21 06:25:27 EST
The requires-half added to rawhide too now.

Note You need to log in before you can comment on or make changes to this bug.