From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: 01/01: gnu: dbus-glib: Propagate inputs dbus and glib. Date: Sun, 24 May 2015 10:33:05 -0400 Message-ID: <87lhge11we.fsf@netris.org> References: <20150523153249.19884.3207@vcs.savannah.gnu.org> <87zj4ulw8g.fsf@netris.org> <20150524073431.GA3725@debian> <87382m86c6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54619) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YwWxq-0005pV-LC for guix-devel@gnu.org; Sun, 24 May 2015 10:33:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YwWxm-0001e8-QZ for guix-devel@gnu.org; Sun, 24 May 2015 10:33:18 -0400 In-Reply-To: <87382m86c6.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 24 May 2015 15:15:21 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Commit 2e88d11 suggests that dbus-glib-1.pc mentions GLib and DBus. > That=E2=80=99s one of the two criteria that we use to add propagate input= s. > So that part of the commit is OK. > > As for removing DBus and GLib as inputs of the other packages, it=E2=80= =99s > 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=E2=80=99t 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 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 abo= ut > dbus and glib, which would not be included. If it first complains about g= lib, > then dbus, then dbus-glib, I would add all three and maybe not even see t= hat > 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 i= ts > 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