Comment 56 for bug 336634

(In reply to comment #21)
> It's not the static libraries that make the difference. It's that we need the
> headers and the .so regardless.
No we don't. And this is exactly what the current bug report try to address.(look at the title).
Despite it should have been made in the pkgconfig directly instead.

In this case, using GConf2-devel doesn't requires dbus-devel at all as;
when building an application using GConf2-devel:
- The GConf2-devel headers doesn't use dbus headers explicitely. (it will use glib2-devel and popt-devel as shown by "grep include /usr/include/gconf/2/gconf/* -R" )
- The app using GConf2-devel shouldn't explicitly use dbus-devel as a mandatory requirement in order to build (as it will not use dbus headers directly either).
- As we link to a shared GConf2, we only need to pass -lGConf2 and libs fetched from Requires: so we don't get undefined-non-weak-symbol since thoses are potentially exposed from the API.

- Since We are not using headers from Requires.private in GConf2 and dependent application, the include path and definition that can eventually be present there aren't needed also. It ends that the whole cflags from Requires.private aren't needed at all( even if using pkgconfig -static.)

- It was working fine previously, and rpmlint didn't reported undefined-non-weak-symbol on a GConf2 dependent package AFAIK).

Now I'm all for you to point me a case where the use of Requires.private is correct in a package as starting point; So I can understand how pkgconfig should handle it.

Just as a note. If a given -devel is installed, the .so and headers will be there, but not the static library. If a given -static library is installed, then it will requires the -devel (which will requires the .so and header).

>... In the bug you referenced, gconf2-devel doesn't
> have a BR on dbus-devel, so you can remove dbus-devel without removing
> gconf2-devel. However, you need the dbus headers (and library) to use
> gconf2-devel, right?
Nope, it was working fine previously and the bugreport started with the pkg-config updates.

> like you could have compiled and linked a GConf app without dbus-devel
> installed.
That was how it behaved previously, and it worked like a charm.

Now I want you to answear few questions:

1 - Why pkg-config should look at Requires.private when not using -static ?

2 - Why either Requires.private (and Libs.private after all) aren't emptied when --disable-static is made. (static library is disabled at build time).

3 - When both shared and static version are built and only the shared version is shipped, Why the requires of the -devel package should cover the needs of the static case ? (which will be larger than the shared only accurate requirements).

4 - When should a library use -static with pkgconfig dependencies ?

5 - When should a binary use -static with pkgconfig dependencies ?

6 - What is the correct behaviour between theses two:
Whith the pkg-config GA behaviour:
[root@kwizatz gconf]# pkg-config --cflags gconf-2.0
-I/usr/include/gconf/2 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
With the current pkg-config updates behaviour:
[root@kwizatz gconf]# pkg-config --cflags gconf-2.0
-DORBIT2=1 -pthread -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include

7 - as you said in c#13:
>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.
Why Cflags are fetched from Requires.private if not using -static instead of just using Cflags from the given .pc ?

8 - As I'm building a package using GConf2-devel, I have:
Requires.private: ORBit-2.0 dbus-1
How can I do if I want to link to a shared version of dbus , but a static version or ORBit-2.0 ?