From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Thompson Subject: Re: Copying whole /gnu/store from USB does not work Date: Fri, 10 Apr 2015 09:41:16 -0400 Message-ID: <87k2xkdrsz.fsf@fsf.org> References: <20150410084651.GA23353@thebird.nl> <873848p5kd.fsf@gnu.org> <20150410131420.GB24509@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41214) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgZBP-0007hm-M4 for guix-devel@gnu.org; Fri, 10 Apr 2015 09:41:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgZBO-00011V-C1 for guix-devel@gnu.org; Fri, 10 Apr 2015 09:41:19 -0400 In-Reply-To: <20150410131420.GB24509@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 , Ludovic =?utf-8?Q?Court=C3=A8?= =?utf-8?Q?s?= Cc: guix-devel@gnu.org Pjotr Prins writes: > Now we need to add Ruby gems and GNU Guix will be the default > deployment system for many. Help wanted. ;) Two major problems to deal with: 1) Propagated inputs: Dynamic languages typically don't have an equivalent to RUNPATH for ELF binaries. Thus, for Python (and others), we have to propagate all of the python libraries along with each package so that they can all be found in a particular load path. This in unideal. I haven't found a way to hardcode the location of libraries as part of the build process. If it can't be reasonably solved, we'll just propagate the inputs like every other dynamic language. Do you know a way that we could avoid this for Ruby gems? 2) Circular dependencies: Rspec is a particularly important Ruby gem to package. Pretty much every Ruby project uses it for their test suite. However, a lot of Rspec's dependencies use Rspec! The only thing I've come up with is to produce a set of private packages for all of Rspec's dependencies whose build processes skip the test suite. Then, with Rspec packaged, create public versions of the packages with Rspec as a native input and the test suite enabled. The dependency tree isn't exactly shallow, though. The Rspec maintainer failed to understand this issue, because the system in place at rubygems.org doesn't run test suites or build the gems at all. People just upload the final product and no one notices that there's nasty circular dependencies. Thoughts? Nice to see you poking around with Guix again, Pjotr. -- David Thompson Web Developer - Free Software Foundation - http://fsf.org GPG Key: 0FF1D807 Support the FSF: https://fsf.org/donate