© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
But there is a concrete specification and implementation.
Requires: Recursively fetch Cflags and Libs from listed dependencies. Recursively fetch Libs.private if --static is specified.
Requires.private: Recursively fetch Cflags from listed dependencies. Recursively fetch Libs and Libs.private if --static is specified.
This is what vanilla pkg-config does. What pkg-config doesn't do well is handle the non-existence of .pc files when they aren't needed. In the fdo bug, the reporter is talking about --exists. We can probably agree that pkg-config shouldn't need to recursively search for listed Requires* because we only want to know about the existence of the .pc metadata for the requested package.
In this bug, the problem is that pkg-config keeps searching for .pc files for listed Requires.private even though the user has requested a case where they're not needed: --libs. It would be better if pkg-config didn't search for the listed .pc file in this case, but having it act like Libs.private is wrong because the Cflags are always needed. Another mode is needed than ignore_private_libs to handle that correctly. In the fdo bug, I have a patch which does just that, adding a ignore_
https:/
What I'm proposing is to punt on that issue for now by making rpm add autoreqs for packages listed in Requires and Requires.private. After all, you do need the -devel package for Requires.private packages installed to actually do anything useful because you need the headers and .so links. I.e., libXmu-devel should require libXext-devel since you actually need the headers and libXext.so/.a to compile a libXmu program. While calling `pkg-config --libs xmu' shouldn't strictly need libXext-devel to be installed, it is a lower priority failure than the failure to actually compile and link a libXmu program.