From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: Re: some questions about GUIX Date: Wed, 30 Dec 2015 21:02:53 -0500 Message-ID: <20151231020253.GA23561@jasmine> 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]:45448) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aESZt-0004t6-1H for help-guix@gnu.org; Wed, 30 Dec 2015 21:02:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aESZp-0006yt-QP for help-guix@gnu.org; Wed, 30 Dec 2015 21:02:56 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:52647) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aESZp-0006yS-9o for help-guix@gnu.org; Wed, 30 Dec 2015 21:02:53 -0500 Content-Disposition: inline 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 On Wed, Dec 30, 2015 at 01:36:12PM +0000, Sam Halliday wrote: > Hi Ricardo, > > I have a few more questions about your proposed jar packaging. > > Ricardo Wurmus writes: > > We are building library for library as individual packages in Guix. We > > certainly won’t bundle prebuilt jars from Maven if it can be avoided > > at all. > > Does this mean that you have a GUIX package for every jar? If so, can > you have multiple versions of the same jar installed at the same time? > 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. Yes, we can have multiple versions of every library installed at the same time, and users of those libraries are linked to a specific library at build time. Our goal is to build everything from source. We even build documentation such as manpages and PDFs from source wherever possible. And if upstream software distributors do not clearly specify which versions of dependent libraries are compatible, instead choosing to bundle binary artifacts of those libraries without providing instructions for rebuilding from source, I'd call that a security risk and affront to users' freedom. > > 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. I'm not a Java programmer so I can't get very deep into the specifics. I have tried to package some Java software, though. I can say that we are actively working towards being able to reproducibly build all the software we package, and so "postfixing" the version for a new build of the same source is unnecessary once we have established that a particular code base can be built reproducibly. In fact, in Guix, trying to rebuild the same source code will only start an actual compilation if the GNU store [0] does not include the memoized output of the last build. Postfixing the binary name sounds like a last-ditch attempt to keep track of binary artifacts that have no clear provenance, using build systems and distribution methods that do not empower [1] downstream users to build software from source. If you find Guix interesting but somewhat confusing, I recommend you spend some time learning more about it, and please keep asking questions! You may find Guix a breath of fresh air after wondering if "guava-18.0-guix1" included that one special platform-specific bug fix or tweak, or if it was "guava-18.0-guix2" ;) Several of us read this blog post [2] on the state of Java packaging recently. It echoed my experiences trying to package Java software and it clearly explains the potential negative consequences of the current methods, and it says it all better than I can. [0] https://www.gnu.org/software/guix/manual/html_node/The-Store.html [1] In some cases it is so difficult that it may as well be closed source. Free software (or open-source, as the license may be) in name only, if you ask me. [2] http://www.vitavonni.de/blog/201504/2015042601-big-data-toolchains-are-a-security-risk.html > > > -- > Best regards, > Sam