From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pjotr Prins Subject: Foreign packages and reproducibility (formerly Re: [PATCH] gnu: Add ruby-nokogiri) Date: Sun, 21 Feb 2016 18:22:31 +0100 Message-ID: <20160221172231.GA30227@thebird.nl> References: <20150713130956.GC28969@thebird.nl> <877fq4i41n.fsf@elephly.net> <20150714090613.GA1523@thebird.nl> <20160217223708.GA7805@thebird.nl> <56C4FCB6.2080108@uq.edu.au> <20160218062534.GA9060@thebird.nl> <87io1i48k5.fsf@elephly.net> <56C9A4A3.9070602@uq.edu.au> <20160221120520.GB29139@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54454) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXXjN-00055R-Ok for guix-devel@gnu.org; Sun, 21 Feb 2016 12:23:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aXXjK-00042Q-Iu for guix-devel@gnu.org; Sun, 21 Feb 2016 12:23:37 -0500 Received: from mail.thebird.nl ([95.154.246.10]:35309) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXXjK-000428-Co for guix-devel@gnu.org; Sun, 21 Feb 2016 12:23:34 -0500 Content-Disposition: inline In-Reply-To: <20160221120520.GB29139@thebird.nl> 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: Pjotr Prins Cc: "guix-devel@gnu.org" I am thinking about this again. It is relevant for all interpreters. The real pain is that between Ruby interpreters the profile can be shared which contains a path to the modules, e.g. say ruby-nokogiri. Currently you can run guix package -i ruby ruby-nokogiri ruby -e "require-2.2.1 'nokogiri'" next update ruby to a new (minor) version guix package -i ruby-2.2.2 and run again ruby -e "require 'nokogiri'" will work. which is wrong because nokogiri was built against the first ruby interpreter. It is a problem from the view point of reproducible software execution. To prevent this we should *not* allow modules (i.e. nokogiri) in the profile. But now a user doing a simple ruby -e "require 'nokogiri'" will fail, because the interpreter does not know where nokogiri is. This is wrong because users should be able to access installed gems (that is the point of having gems!). One suggestion is wrappers and runpaths. I.e. wrap the invocation of 'ruby' with a script that will pass in the path to all installed gems. Q1: is there a limitation to the length of such a path (generally a bash variable)? Q2: would the wrapper be updated every time a new gem gets installed? How can we be sure it is deterministic? Installation order may matter. Q3: can we query guix on-the-fly for paths to all leaf nodes that depend on a ruby? That way a wrapper could be installed once. Would that be too slow? How can we be sure it is deterministic? I do not know how nix solves it exactly, but I do know they use a wrapper script. Finally, I do think that most Ruby gems should propagate ruby itself. Only rarely are gems executables. Mostly they are libraries, which implies you need to run ruby to run them. Right? It does not make sense to install a Ruby library without the ruby interpreter. Pj.