From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH] gnu: Add Nmap. Date: Mon, 24 Nov 2014 15:22:26 +0100 Message-ID: <87r3ws1xwd.fsf@gnu.org> References: <87zjbi99hs.fsf@taylan.uni.cx> <20141123090224.GA8260@debian> <87vbm68743.fsf@taylan.uni.cx> <87mw7h4pqf.fsf@gnu.org> <87k32l8oid.fsf@taylan.uni.cx> 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]:53696) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsuXH-0003np-PC for guix-devel@gnu.org; Mon, 24 Nov 2014 09:22:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XsuX9-0006Su-Pw for guix-devel@gnu.org; Mon, 24 Nov 2014 09:22:39 -0500 Received: from hera.aquilenet.fr ([2a01:474::1]:38369) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsuX9-0006Sm-B1 for guix-devel@gnu.org; Mon, 24 Nov 2014 09:22:31 -0500 In-Reply-To: <87k32l8oid.fsf@taylan.uni.cx> ("Taylan Ulrich \=\?utf-8\?Q\?\=5C\=22Bay\=C4\=B1rl\=C4\=B1\=2FKammer\=5C\=22\=22's\?\= message of "Mon, 24 Nov 2014 00:51:06 +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: Taylan Ulrich =?utf-8?Q?=22Bay=C4=B1rl=C4=B1?= =?utf-8?Q?=2FKammer=22?= Cc: guix-devel@gnu.org taylanbayirli@gmail.com (Taylan Ulrich "Bay=C4=B1rl=C4=B1/Kammer") skribis: > 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. Thanks, that seems like the best option. > 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? Yes. (There may be rare exceptions, but this is not one of them.) Here you want users to be able to run =E2=80=98zenmap=E2=80=99 (or whatever= the command is called) and have it Just Work, regardless of whether they happen to have installed Python and Python-GTK as well. So that means that the zenmap (or nmap) package basically needs to =E2=80=9Cclose over=E2=80=9D these inputs, probably using =E2=80=98wrap-pro= gram=E2=80=99. > 2) If purely-run-time dependencies are inputs, won't that trigger > unnecessary rebuilds of the package when a run-time dependency is > updated? It=E2=80=99s rarely be =E2=80=9Cpurely run-time=E2=80=9D. Normally, at the= very least there=E2=80=99s a configure script that makes sure at build-time that the dependencies are satisfied, and a test suite that makes sure things work. > 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 whole functional approach things means that bindings are static (again, there may be exceptions, but zenmap has nothing exceptional here.) > 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.) You=E2=80=99re describing an imperative packaging system. This is fine, bu= t it defeats the whole idea of functional packaging. :-) See and for the rationale. > 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.) Build tools are listed in =E2=80=98native-inputs=E2=80=99. > "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= works > extremely well." > > Perhaps we already do that? Yes. That means that run-time dependencies are a strict subset of build-time dependencies. I hope this clarifies things. Otherwise let me know! Thanks, Ludo=E2=80=99.