Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=541535 --- Comment #3 from Michael Schwendt <mschwendt@xxxxxxxxx> 2009-12-05 19:36:52 EDT --- > LD_LIBRARY_PATH vs. LD_PRELOAD The benefit would be that you would test run-time linking of the test-suite programs with the actual shared libs installed into the package buildroot. It's much more a real-world test scenario than forcefully making available a .so that won't even be put into the run-time library package. > A "Requires" in the devel package does not necessarily mean > that you need that package during building. I found it surprising enough to mention it. :-) Upstream could include a check for liblo in its build framework. Afterall, it's a requirement of the API. > Should I remove these entries from the .pc file: Raises the question whether you would like the increased maintenance requirements? [pkg-config is kind of unflexible in that area. For any inter-dependency on other .pc files that is added in a .pc file's "Requires" line, it propagates and accumulates the cflags and ldflags. Good for the cflags (to find headers in customised trees outside standard search paths). However, when linking shared-only, we don't need to relink against shared libs a base library is linked with already (as opposed to static linkage). So, as an affect, shared library ldflags pile up even if an API doesn't depend on any of the libs.] And in this case the author even specified all those cflags and ldflags manually instead of using dependencies. > I don't know of any software that uses redlandmm feature of raul. The cleaner work-around would be to %exclude those headers then and effectively disable that part of the API that could not be used. We can't ship an API that is defunctional because of missing headers. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review