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

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

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

> andreas pushed a commit to branch master
> in repository guix.
>
> commit 2e88d113aac31dbea0b998fca92b35dbfc998872
> Author: Andreas Enge <andreas@enge.fr>
> Date:   Sat May 23 16:43:18 2015 +0200
>
>     gnu: dbus-glib: Propagate inputs dbus and glib.
>     
>     * gnu/packages/glib.scm (dbus-glib): Propagate inputs dbus and glib.
>     * gnu/packages/audio.scm (patchage),
>       gnu/packages/gnuzilla.scm (icecat),
>       gnu/packages/python.scm (python-dbus): Drop inputs dbus and glib.
>     * gnu/packages/gnome.scm (colord, gconf, gnome-vfs, upower),
>       gnu/packages/mail.scm (claws-mail),
>       gnu/packages/messaging.scm (hexchat),
>       gnu/packages/wicd.scm (wicd): Drop input dbus.

The only change you actually made to messaging.scm in this commit was to
add your copyright notice.

However, I have a larger question about this commit: Should 'dbus' and
'glib' be removed from the inputs of every package that has 'dbus-glib'
as an input?  My answer would be "not necessarily".  IMO, the only time
we should remove input A from a package is when it doesn't use A
directly.

Allow me to make an analogy to C include files:

Suppose I have a program that uses both 'printf' and 'ptrdiff_t', which
are documented as being declared in 'stdio.h' and 'stddef.h'
respectively.  Now, I might be clever and realize that 'stdio.h'
includes 'stddef.h', so I needn't include both.  However, I would argue
that this is bad practice for multiple reasons.  The practical reason is
that if 'stdio.h' stops including 'stddef.h' in the future for some
reason, my code will break.

On the other hand, if I have a program that doesn't need anything from
'stddef.h' but only included it to work around the fact that 'stdio.h'
needs 'stddef.h' and forgot to include it, then of course after that's
fixed it makes sense to remove the workaround.

Does that make sense?

       Mark

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

[Andreas Enge]

On Sat, May 23, 2015 at 07:17:35PM -0400, Mark H Weaver wrote:
> The only change you actually made to messaging.scm in this commit was to
> add your copyright notice.

That was a mistake, I intended to make the change announced in the commit
message. Probably a consequence of juggling with too many files, since I
also built all the modified packages (with the exception of icecat) to make
sure everything still works.

> However, I have a larger question about this commit: Should 'dbus' and
> 'glib' be removed from the inputs of every package that has 'dbus-glib'
> as an input?  My answer would be "not necessarily".  IMO, the only time
> we should remove input A from a package is when it doesn't use A
> directly.

I have no definite answer to this. Not removing them would definitely mean
less work. Even more so since it is not easy to determine the transitive
closure of propagation: If A is propagated by B and B is propagated by C,
then everything including C does not need to include A.

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.

Contrarily to you, I wondered whether we should not even build a linter to
verify if propagated inputs could not be dropped as explicit inputs... But
I think it would make for a lot of work with little effect anyway.

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

Andreas

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

[Ludovic Courtès]

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.

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

Thanks,
Ludo’.

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

[Mark H Weaver]

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

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

[Andreas Enge]

On Sun, May 24, 2015 at 10:33:05AM -0400, Mark H Weaver wrote:
> ludo@gnu.org (Ludovic Courtès) writes:
> > 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.

Okay, both are fine with me.

> 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.

Also okay then. It also saves quite some time...

Andreas

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

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Sun, May 24, 2015 at 10:33:05AM -0400, Mark H Weaver wrote:
>> ludo@gnu.org (Ludovic Courtès) writes:
>> > 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.
>
> Okay, both are fine with me.

OK with Mark’s suggestion.

Ludo’.