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 21:52:50 +0100 Message-ID: <87egss8gnx.fsf@taylan.uni.cx> References: <87zjbi99hs.fsf@taylan.uni.cx> <20141123090224.GA8260@debian> <87vbm68743.fsf@taylan.uni.cx> <87mw7h4pqf.fsf@gnu.org> <87k32l8oid.fsf@taylan.uni.cx> <87r3ws1xwd.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]:56549) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xt0cy-0006P3-2L for guix-devel@gnu.org; Mon, 24 Nov 2014 15:52:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xt0cw-0007HB-Av for guix-devel@gnu.org; Mon, 24 Nov 2014 15:52:56 -0500 In-Reply-To: <87r3ws1xwd.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Mon, 24 Nov 2014 15:22:26 +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: > 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-p= rogram=E2=80=99. Thanks for the pointer; I'll look into 'wrap-program'. >> 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 t= he 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. You're right; now that I think of it, it's probably a bug that Nmap's build process doesn't check for the presence of a GTK module. I'll talk to their developers to clarify. (ML thread should pop up at the bottom of http://seclists.org/nmap-dev/2014/q4/index.html soon.) >> 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 That's a neat analogy. :-) However, we needn't recompile C code when there's an update to some dynlang library the program uses, do we? Then again, we want to re-run a potential test suite that might be using that library. I guess it's OK to be "conservative" for now, until One Day=E2=84=A2 we can be more precise and separate testing from building... (If that day comes though, we better find a way to automatically discern run-time-only inputs. (Regarding test suites to be "run-time" too.) Otherwise we'll have a lot to do.) Also, configure scripts that check for such dynlang libraries' presence might become a problem. I imagine one could provide some for-building version of said library that's merely of the same major version, to "shut up" the configure script, since it only gets in the way in this case. (Complaining about the lack of a run-time dependency, at build-time... Yes, above I said *not* doing this is probably a bug in Nmap's build process, but for us it would become an annoyance.) Alternatively, the script might simply take a flag telling it to enable a feature even if it can't find a run-time dependency; I don't how many configure scripts have this. >> 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, = but > it defeats the whole idea of functional packaging. :-) > > See and > for the rationale. Same thing as above really. Until the ABI of a dylib changes, updates to it needn't ignite recompilation of C code which uses that lib; it won't affect the compiler output anyway. (Tell me if I'm technically wrong; not an expert on C compilation etc.) But again, test suites... It does sound like breaking functional purity, but is it really so when an input has *no* effect on a build process other than the test suite? Once the test suite is separated, the real package and for-building package become operationally equivalent under the given build process, so providing one in place of the other would be a correctness preserving optimization. :-) >> 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. Ah, thanks for clarifying. (BTW 'native-inputs' seems undocumented.) In that case, we should already be able to do at least this, no? (The other ideas are sadly high up in the air.) It could have prevented world-rebuilds upon the bash security patches, for example. (Given it's acceptable to use a buggy (even security-holy) Bash for some ./configure scripts and the like, so long as it doesn't break specifically them.) >> "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 see. One confusion remains: wouldn't that mean it would drop a dependency such as the Python GTK module in our case, because its hash doesn't appear anywhere, and instead it's only referenced by module name which is expected to be in some Python load path at run-time? Thanks a lot and sorry for taking your time! I might be dumping out many dubious ideas. Taylan