[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 01/01: gnu: dbus-glib: Propagate inputs dbus and glib.
From: |
Andreas Enge |
Subject: |
Re: 01/01: gnu: dbus-glib: Propagate inputs dbus and glib. |
Date: |
Sun, 24 May 2015 09:34:31 +0200 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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