From mboxrd@z Thu Jan 1 00:00:00 1970 From: taylanbayirli@gmail.com (Taylan Ulrich =?utf-8?Q?Bay=C4=B1rl=C4=B1?= =?utf-8?Q?=2FKammer?=) Subject: Re: [PATCH] gnu: Add Nmap. Date: Mon, 24 Nov 2014 00:51:06 +0100 Message-ID: <87k32l8oid.fsf@taylan.uni.cx> References: <87zjbi99hs.fsf@taylan.uni.cx> <20141123090224.GA8260@debian> <87vbm68743.fsf@taylan.uni.cx> <87mw7h4pqf.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]:49708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xsgvv-000743-6c for guix-devel@gnu.org; Sun, 23 Nov 2014 18:51:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xsgvu-0006P2-1I for guix-devel@gnu.org; Sun, 23 Nov 2014 18:51:11 -0500 In-Reply-To: <87mw7h4pqf.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 23 Nov 2014 21:38:16 +0100") 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: > This is normally dealt with by using multiple outputs (info "(guix) > Packages with Multiple Outputs"). An example of that is Git: the Tcl > GUIs are moved to a separate output, and so is git-svn support, such > that the main output does not depend on Tcl, libx11, Subversion, etc. OK, will have a go at this. It seems Zenmap doesn't need X11/GTK libraries (rather headers) at build time because it only uses a Python GTK module. This raises two general questions for me: 1) Is it OK if users have to install additional packages for a given component of a package to work, or should all dependencies, even if purely run-time, be inputs? 2) If purely-run-time dependencies are inputs, won't that trigger unnecessary rebuilds of the package when a run-time dependency is updated? (In this special case only question 2 applies, because the whole of Zenmap is useless without GTK, not just a component of it.) After some pondering, I would say: 1) There should be a way to run-time-depend on another package without it being a build input at all. (The installation of these needn't be forced on the user, though in some cases like Zenmap it's senseless not to do so; we could have "dependencies" and "recommendations" and possibly more, like in Debian.) 2) When interface files of a dylib are needed during compilation of a static lang (e.g. C headers), a special for-building package should be used as input, thus the actual dylib can be updated without causing rebuilds. (Until ABI compatibility breaks I guess.) 3) Similarly, when a program is needed purely at build-time, like Bash or SCons, a special for-building package should be used as input, thus the actual program can be updated without causing rebuilds. (The for-building package would be updated only when doing so will improve the builds, like when a newer GCC version optimizes better.) 4) The for-building packages in #3 should obviously not be installed on the user's machine (unless they build locally instead of using binary substitutes), meaning "build inputs" and "run-time dependencies" are fully orthogonal. In the Nix manual I see the following, which possibly fixes #4 without needing to separate build inputs from run-time dependencies in recipes: "Runtime dependencies are found by scanning binaries for the hash parts of Nix store paths (such as r8vvq9kq=E2=80=A6). This sounds risky, but it w= orks extremely well." Perhaps we already do that? But otherwise, it seems like we could save gigawatts of electricity over time with #1-3. Please tell me if I'm missing something obvious. :-) Taylan