Re: 01/01: gnu: dbus-glib: Propagate inputs dbus and glib.

[Mark H Weaver <mhw@netris.org>]

ludo@gnu.org (Ludovic Courtès) writes:

> Commit 2e88d11 suggests that dbus-glib-1.pc mentions GLib and DBus.
> That’s one of the two criteria that we use to add propagate inputs.
> So that part of the commit is OK.
>
> As for removing DBus and GLib as inputs of the other packages, it’s
> really a question of whether the package uses them directly or not, as
> Mark wrote.  This would need to be checked for each of them.  The
> conservative approach would be to leave DBus and GLib as inputs until we
> have evidence that the package in fact only needs dbus-glib.

Agreed.

> Should we revert that part of the commit, at least for packages for
> which we don’t know?

FWIW, I don't feel the need to revert, especially since it would entail
more rebuilding, but in the future I would prefer to use the more
conservative approach that you outlined above.


Andreas Enge <andreas@enge.fr> writes:

> In practice, for a new package, I am usually building with incrementally more
> inputs, following the complaints by the configure phase. So if it first
> complains about dbus-glib, I would add it, and not see any complaints about
> dbus and glib, which would not be included. If it first complains about glib,
> then dbus, then dbus-glib, I would add all three and maybe not even see that
> one of them is enough.

Fair enough :)  I suspect that's the way most of our packages were built,
and that's okay.  For that matter, I suspect that's the way most authors
of C files determine which header files to #include.

> So maybe we should not do anything special and just let randomness take its
> course in this matter?

I don't think we should spend a lot of time on this, but to the extent
we are aware of which inputs are directly needed by a given package, I
think we should aim to include all directly used inputs, as opposed to
aiming to remove inputs whenever they are propagated by something else.

      Mark