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: Tue, 25 Nov 2014 22:09:25 +0100 Message-ID: <87bnnvxa0q.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> <87r3ws1xwd.fsf@gnu.org> <87egss8gnx.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]:52363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtNMa-0002BI-VI for guix-devel@gnu.org; Tue, 25 Nov 2014 16:09:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XtNMV-00062C-Bq for guix-devel@gnu.org; Tue, 25 Nov 2014 16:09:32 -0500 Received: from hera.aquilenet.fr ([2a01:474::1]:39899) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtNMU-000628-TF for guix-devel@gnu.org; Tue, 25 Nov 2014 16:09:27 -0500 In-Reply-To: <87egss8gnx.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 21:52:50 +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: [...] >> The whole functional approach things means that bindings are static > > That's a neat analogy. :-) It=E2=80=99s not just an analogy, it=E2=80=99s really what happens. > However, we needn't recompile C code when there's an update to some > dynlang library the program uses, do we? Yes we 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. Most of the time, packages check at configure-time whether their perquisites are available. Then, their test suite use these specific dependencies. Finally, in the case of DSOs, the RUNPATH makes sure that these specific dependencies are used at run time. Then there=E2=80=99s the case of dynamic languages with no RUNPATH equivale= nt. In that case we arrange with =E2=80=98propagated-inputs=E2=80=99 or with wr= appers to make sure the =E2=80=9Cright=E2=80=9D dependencies are used at run time. I=E2=80=99m not sure if that answers your concerns, does it? > 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.) At the very least, the RUNPATH will be different. But then, keep in mind we=E2=80=99re aiming for complete reproducibility. = So we can=E2=80=99t rely on things like =E2=80=9Coh, developers say this version = is ABI-compatible with the previous one.=E2=80=9D > 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? That=E2=80=99s an important effect: it means that the test suite is known to work this particular input. > 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. :-) Yeah, I see where you=E2=80=99re going. :-) Eelco Dolstra=E2=80=99s PhD t= hesis on Nix had that idea of =E2=80=9Cequivalence classes=E2=80=9D. It=E2=80=99s not v= ery practical, though. > 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.) See =E2=80=9CSecurity Updates=E2=80=9D in the manual for that. >>> "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? Correct. That=E2=80=99s why we=E2=80=99d either use =E2=80=98propagated-in= puts=E2=80=99 or =E2=80=98wrap-program=E2=80=99, depending on the situation. I hope this clarifies things. So, where were we with this nmap patch? :-) Ludo=E2=80=99.