[Xcb] [PATCH] Move internal/private dependencies to Requires.private

[Ran Benita]

On Sun, Sep 07, 2014 at 04:25:24PM +0100, Emil Velikov wrote:
> On 07/09/14 16:06, Ran Benita wrote:
> > On Fri, Sep 05, 2014 at 01:46:40AM +0100, Emil Velikov wrote:
> >> Program using the xcb sub-modules has indirect compile and runtime
> >> dependency of core xcb. To ensure this out we currently list xcb in
> >> the Requires field of the pkg-config files. While this provides all
> >> the required dependencies for successful compilation this causes
> >> over-linking and hides potential linking miss-use against the xcb modules.
> > 
> > Can you describe a bit more what sort of linking misuses? (Besides
> > overlinking which I don't think applies in this case)
> > 
> Overlinking applies for all the users of the xcb modules/plugins, as
> effectively every user will be linked against core xcb even if it's not needed.

I don't see anyone using an xcb module function without ever needing at
least an xcb connection.

> The miss-use (albeit unlikely):
> Library A, uses core xcb' function X (v1.2) and xcb-bla. xcb-bla is linked
> against core xcb where function X (v1.1) is not compatible with the one used by A.
> Currently A will link against X v1.1 and will try to use v1.2. Bad stuff will
> happen at the moment it tries to use the function. With this change things
> will "explode" upon startup - not perfect solution but a better one imho.

I'm sorry, I tried to follow but failed. Maybe it's just me being dumb :)
Would you mind rephrasing, and say what is compiled against what version and
what is linked against what version and how (DT_NEEDED or explicit -l)?

> >> By moving to Requires.private we retain the compilation and runtime
> >> compatibility and avoids any runtime problems.
> > 
> > I see the xcb modules as more of "addons" or "plugins" to libxcb than
> > just depending on it. And it is quite impossible to use these modules
> > without directly using libxcb. So "-lxcb-xkb" would look a bit strange,
> > I'd rather always have "-lxcb -lxcb-xkb".
> > 
> So in that case pick up what you're using rather going for the guesswork that
> the right one is picked :)

I agree. But you're dealing with expectations.. And historically/in
practice the rule hasn't been "everything uses Requires.private". Looking
through /usr/lib/pkgconfig on my system, there are the following (what
appear to be) addon-style libraries:

avahi-* cairo-* clutter-* cogl-* gtk+-* gstreamer-* harfbuzz-* icu-*
libnl-* libsystemd-* libunwind-* libva-* m17n-* mit-krb5-* poppler-*
wayland-* xcb-* xkbcommon-*

If I got it right, all besides mit-krb5-gssapi use Libs or Requires for
their base library.

> >> Cc: Keith Packard <keithp at keithp.com>
> >> Cc: Alan Coopersmith <alan.coopersmith at oracle.com>
> >> References: http://people.freedesktop.org/~dbn/pkg-config-guide.html#faq
> >> References: https://wiki.mageia.org/en/Overlinking_issues_in_packaging
> >> References: http://err.no/personal/blog/2008/Mar/25
> > 
> > The referenced pkg-config-guide page says: "[...] it is usually only
> > appropriate to add modules from the same package in Requires."
> > 
> > There's also this page which discusses these directives:
> > https://www.flameeyes.eu/autotools-mythbuster/pkgconfig/dependencies.html
> > 
> Please take a look at [1] and [2]. Also there was a lengthy discussion on
> #xorg-devel which you might find interesting.

All of the arguments from the referenced mails/blogs (besides your misuse
case above) AFAICT boil down to overlinking, which I don't think is
relevant in cases like this.
I missed the IRC discussion. Sounds like the XCB devs agreed so sorry for
barging in.

Having said all that, I see your argument for trying to get everything
to use Requires.private as the sane default, unless there's a real
technical argument for using Requires (which mostly there isn't). So
consider me neutral - don't hold the patch because of me.

Ran

> -Emil
> 
> [1] http://lists.freedesktop.org/archives/xcb/2014-August/009617.html
> [2] http://lists.freedesktop.org/archives/xcb/2014-August/009654.html