guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mark H Weaver
Subject: Re: 01/01: gnu: dbus-glib: Propagate inputs dbus and glib.
Date: Sun, 24 May 2015 10:33:05 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

address@hidden (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 <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]