* Re: 01/01: gnu: dbus-glib: Propagate inputs dbus and glib.
[not found] ` <E1YwBPu-0005Be-7W@vcs.savannah.gnu.org>
@ 2015-05-23 23:17 ` Mark H Weaver
2015-05-24 7:34 ` Andreas Enge
0 siblings, 1 reply; 6+ messages in thread
From: Mark H Weaver @ 2015-05-23 23:17 UTC (permalink / raw
To: Andreas Enge; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 01/01: gnu: dbus-glib: Propagate inputs dbus and glib.
2015-05-23 23:17 ` 01/01: gnu: dbus-glib: Propagate inputs dbus and glib Mark H Weaver
@ 2015-05-24 7:34 ` Andreas Enge
2015-05-24 13:15 ` Ludovic Courtès
0 siblings, 1 reply; 6+ messages in thread
From: Andreas Enge @ 2015-05-24 7:34 UTC (permalink / raw
To: Mark H Weaver; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 01/01: gnu: dbus-glib: Propagate inputs dbus and glib.
2015-05-24 7:34 ` Andreas Enge
@ 2015-05-24 13:15 ` Ludovic Courtès
2015-05-24 14:33 ` Mark H Weaver
0 siblings, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2015-05-24 13:15 UTC (permalink / raw
To: Andreas Enge; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 01/01: gnu: dbus-glib: Propagate inputs dbus and glib.
2015-05-24 13:15 ` Ludovic Courtès
@ 2015-05-24 14:33 ` Mark H Weaver
2015-05-24 20:14 ` Andreas Enge
0 siblings, 1 reply; 6+ messages in thread
From: Mark H Weaver @ 2015-05-24 14:33 UTC (permalink / raw
To: Ludovic Courtès; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 01/01: gnu: dbus-glib: Propagate inputs dbus and glib.
2015-05-24 14:33 ` Mark H Weaver
@ 2015-05-24 20:14 ` Andreas Enge
2015-05-25 13:17 ` Ludovic Courtès
0 siblings, 1 reply; 6+ messages in thread
From: Andreas Enge @ 2015-05-24 20:14 UTC (permalink / raw
To: Mark H Weaver; +Cc: guix-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 01/01: gnu: dbus-glib: Propagate inputs dbus and glib.
2015-05-24 20:14 ` Andreas Enge
@ 2015-05-25 13:17 ` Ludovic Courtès
0 siblings, 0 replies; 6+ messages in thread
From: Ludovic Courtès @ 2015-05-25 13:17 UTC (permalink / raw
To: Andreas Enge; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-05-25 13:17 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20150523153249.19884.3207@vcs.savannah.gnu.org>
[not found] ` <E1YwBPu-0005Be-7W@vcs.savannah.gnu.org>
2015-05-23 23:17 ` 01/01: gnu: dbus-glib: Propagate inputs dbus and glib Mark H Weaver
2015-05-24 7:34 ` Andreas Enge
2015-05-24 13:15 ` Ludovic Courtès
2015-05-24 14:33 ` Mark H Weaver
2015-05-24 20:14 ` Andreas Enge
2015-05-25 13:17 ` Ludovic Courtès
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.