l...@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 <andr...@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
