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

[Mark H Weaver]

Andreas Enge <address@hidden> writes:

> andreas pushed a commit to branch master
> in repository guix.
>
> commit 2e88d113aac31dbea0b998fca92b35dbfc998872
> Author: Andreas Enge <address@hidden>
> 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