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: Wed, 26 Nov 2014 00:25:22 +0100 Message-ID: <873896982l.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> <87egss8gnx.fsf@taylan.uni.cx> <87bnnvxa0q.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]:52202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtPU9-0007Xv-MV for guix-devel@gnu.org; Tue, 25 Nov 2014 18:25:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XtPU6-0002sJ-00 for guix-devel@gnu.org; Tue, 25 Nov 2014 18:25:29 -0500 In-Reply-To: <87bnnvxa0q.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Tue, 25 Nov 2014 22:09:25 +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: > [large snip] > > I hope this clarifies things. Yes! Thanks for your patience. It now dawns on me that our primary aim isn't byte-equal build process outputs (in terms of file contents); it's "immutable run-time behavior" of a package. That is to say, if /gnu/store/...-foo/bin/foo works fine today, it should work fine any day; it's unacceptable to let it load a different .so than its designated one, unless we define some very strict criteria for the .so and prove that a replacement satisfies them... Similarly for some Python module the program uses. I was chasing a "reproducible builds" red herring. That being said, I still think it's wasteful that C code gets recompiled when there's an update to a dynamic component. A rough idea for the future: save some intermediate build output (say from the 'build' phase), then when there's an update to a run-time component such as a DSO or dynlang module, make a new package that merely receives some tweaks to the saved intermediate output, such as fixing RUNPATH, re-patching shebang lines, etc. Users will still need to download these new packages; that in turn could be improved via binary diffs one day. > So, where were we with this nmap patch? :-) Heh, indeed. I thought I'd wait for feedback from the Nmap ML but I guess that's not necessary. I'll continue working on it tomorrow. Taylan