unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Andreas Enge <andreas@enge.fr>
To: Mark H Weaver <mhw@netris.org>
Cc: guix-devel@gnu.org
Subject: Re: 01/01: gnu: dbus-glib: Propagate inputs dbus and glib.
Date: Sun, 24 May 2015 09:34:31 +0200	[thread overview]
Message-ID: <20150524073431.GA3725@debian> (raw)
In-Reply-To: <87zj4ulw8g.fsf@netris.org>

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

  reply	other threads:[~2015-05-24  7:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150524073431.GA3725@debian \
    --to=andreas@enge.fr \
    --cc=guix-devel@gnu.org \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).