From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: some questions about GUIX Date: Thu, 31 Dec 2015 10:30:12 +0100 Message-ID: <871ta3artn.fsf@elephly.net> References: <87d1ttmdbd.fsf@gmail.com> <87a8ot47wr.fsf@gnu.org> <87vb7h1cwh.fsf@gmail.com> <87a8otax38.fsf@elephly.net> <87lh8cvz1v.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aEZYx-0004DE-8G for help-guix@gnu.org; Thu, 31 Dec 2015 04:30:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aEZYt-0002sC-4a for help-guix@gnu.org; Thu, 31 Dec 2015 04:30:27 -0500 In-reply-to: <87lh8cvz1v.fsf@gmail.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org To: Sam Halliday Cc: help-guix@gnu.org Sam Halliday writes: > Does this mean that you have a GUIX package for every jar? Some packages may provide more than one jar archive. This depends on what the build system prescribes. For every *project* there will be at least one jar, though. > If so, can > you have multiple versions of the same jar installed at the same time? Yes! This is a core feature enabled by functional package management. We treat packages as if they were pure functions in that the exact same set of inputs (source tarballs, compilers, libraries, and their own inputs, and the inputs of those inputs, etc...) produces the exact same output. Instead of computing the output from scratch each time we want to use the value (e.g. as an input to another package or in a profile) we can cache or memoise it. We do this by storing the unique output artifact for a given bag of inputs in /gnu/store; outputs are prefixed with a unique hash that is computed from all inputs. Installing a package then is little more than the act of linking individual items from the store into a profile. We can store any package output in /gnu/store because they all have their very own directory; they don’t overlap. Thus we can install/link different versions into different profiles. > Support for multiple versions of a library will be necessary as it is > not always a simple case of bumping the version to use a library: many > libraries introduce breaking changes at both source and binary level. Correct. We don’t have a problem with this as we never install anything into a “global” namespace (such as /usr, /lib, or whatever). > Will you be using the same version names as the official upstream > binaries? I strongly recommend against doing this. The convention in > corporate environments is that rebuilds of jars incur a postfix to their > version. E.g. a rebuild of guava 18.0 (even with no changes to the > sources) would be 18.0-guix1. Of course, there is no way for you to know > that jars are not being loaded by name at runtime through the > classloader, so you introduce further opportunity for bugs here. FWIW Debian builds Java libraries from sources, too, and they do not rename the resulting jars. There is really no need to do that in Guix anyway, because installing these jars is not going to affect global state — they are not installed in well-known global directories, so they cannot be “picked up” by accident. There is, of course, one potential issue with building Java stuff on Guix that I haven’t assessed yet. I don’t yet know if there’s something in the Java world that’s similar to the RUNPATH feature in native applications, or if visibility of jars is determined exclusively by the clunky CLASSPATH environment variable instead. If there is no way to “link” jars explicitly by their full path, then dependencies need to be propagated and applications may need to be wrapped in an appropriate CLASSPATH, which is somewhat inelegant, but not a real problem. (This is done for Python, R, Perl, and Ruby applications in Guix already, because these languages control module visibility primarily through environment variables.)