I would like to submit a topic on tommorrow FESCo meeting.
According to this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=224148
A patched version of pkgconfig was previously shipped in stable releases (F9/F10) This patch was reverted since it didn't match the vanilla pkgconfig.
Once the vanilla pkgconfig hit the stable updates, some new package started to fail to build from source, since the pkgconfig behaviour changed. (specially around the Requires.private functionality, like https://bugzilla.redhat.com/show_bug.cgi?id=485667 ).
It "could be" possible that some project doesn't use Requires.private as appropriate, but usage of this feature remains unclear. In my case, I have 52 .pc that use Requires.private. Each can potentially introduce BuildFailure for a package using it because of the pkgconfig behaviour change during stable release.
FESCo is been ask for a decision about "How to deal with Requires.private". Here are some suggestion:
1 - Revert to the GA "patched" pkg-config. * This will avoid an epidemic rebuild packages that was working fine previously. - Declare the usage of Requires.private in F9/F10 without effect. - Frooze the usage of Requires.private with pkgconfig upstream (Rawhide) - Audit packages in Rawhide using Requires.private to request a version of pkgconfig supporting it as appropriate. - Eventually Backport the new pkgconfig in stable release.
2 - Stay with the updates "vanilla" pkgconfig and fix all the dependencies. According to the Requires.private vanilla behaviour. * This request the Requires.private usage to be known. In the current situation, it may makes some -devel requirement to grown without reason. Many package will need a rebuild as a side effect. ex: Either move dbus-1.0 from Requires.private to -dbus as Lib.private if the package isn't using dbus headers.
3 - Stay with the updates "vanilla" pkgconfig and hack new packages with workaround. * This will allow to build only new packages as needed. ex: make the update of a package that was previously working, BR dbus-devel to workaround the pkgconfig behaviour change.
The decision was made to stick with the current (reverted) state of things, in order to more closely follow upstream.
Login to comment on this ticket.