Description of problem: %{libdir}/pkgconfig/rpm.pc is broken: # pkg-config --cflags rpm -I/usr/include/ Note the '/' at the end of this line. Version-Release number of selected component (if applicable): rpm-4.6.0-0.rc1.6.i386 Actual results: $(pkg-config --cflags rpm) returns a bogus value. Expected results: $(pkg-config --cflags rpm) should return nothing. Additional info: pkg-config --cflags must not return -I/usr/include rsp. -I/usr/include/, because this disturbs the compiler's default/system include path (/usr/include is implicitly searched). pkg-config even filters out /usr/include. rpm's rpm.pc circumvents this filtering by carrying and explicit "/" in its Cflags: -I${includedir}/
Right.. fixed upstream, Fedora will get it on the eventual update to 4.6.0 final (this is hardly important enough to patch separately and break the freeze)
(In reply to comment #1) > Right.. fixed upstream, Fedora will get it on the eventual update to 4.6.0 > final (this is hardly important enough to patch separately and break the > freeze) Sigh - You are vastly underestimating the potential of such bugs. The problem with it: It's unlikely to hit, because it's unlikely any package in fedora will use rpm's pkgconfig. But if it should hit, the effects likely will be dramatic. Wrt. the freeze - Shall the rel-eng have an interesting life with it.
We have very different ideas of what a dramatic bug is obviously. This wont eat anybodys hard drive for breakfast or cause failed installations/upgrades - that's dramatic for me. There are no current users of rpm's pkg-config so at the worst it affects somebody trying to compile (new) software using librpm C API and even then it's easily avoidable by not using pkg-config. It's a bug and will be fixed, that's all there is to it.
(In reply to comment #3) > We have very different ideas of what a dramatic bug is obviously. Apparently. Your attitude is the typical ignorance RH folks expose when it comes to bugs which don't affect "end-users". > This wont eat anybodys hard drive for breakfast or cause failed > installations/upgrades Right - It won't hurt "normal endusers", but it will hurt packagers and developers. > - that's dramatic for me. There are no current users of > rpm's pkg-config Wrong. We are talking about a *-devel package => it will hurt all developers who are using this newer rpm. Acceptable for RHEL, but unacceptable for a distro aiming at an audience consisting of developers. > so at the worst it affects somebody trying to compile (new) > software using librpm C API and even then it's easily avoidable by not using > pkg-config. Correct. You are wasting one key feature, which would have helped to make rpm.org's attractive.
Sigh. I already said it will be fixed in rpm 4.6.0 final, end of story.
Bug is unfixed in Fedora. Trying to reopen.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fixed in rawhide, F10 will have it as an update after a bit of testing of 4.6.0-rc2 in rawhide.
rpm-4.6.0-0.rc3.1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/rpm-4.6.0-0.rc3.1.fc10
rpm-4.6.0-0.rc3.1.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update rpm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2008-11332
rpm-4.6.0-0.rc3.1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.