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:50:56 +0100 Message-ID: <87ziwr9can.fsf@elephly.net> References: <87d1ttmdbd.fsf@gmail.com> <87a8ot47wr.fsf@gnu.org> <87vb7h1cwh.fsf@gmail.com> <87a8otax38.fsf@elephly.net> <87si2k25hu.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]:33663) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aEZt0-0006nD-G3 for help-guix@gnu.org; Thu, 31 Dec 2015 04:51:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aEZst-0007q2-V2 for help-guix@gnu.org; Thu, 31 Dec 2015 04:51:10 -0500 In-reply-to: <87si2k25hu.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: > Thanks Ricardo, > > Ricardo Wurmus writes: >> I’m not sure I understand what you mean here. I have been packaging a >> couple of Java things and the reliance on prebuilt jars and Maven >> causes quite a few problems. This is the single most important reason >> why there isn’t much of Java to be found in Guix yet. > > If the GUIX-SD goal is to build every package from source, then I can > see why you're doing it this way. It is possible to achieve this noble > goal, but you are embarking on an absolutely *gigantic* mission. It can be quite difficult to do this because many people seem to think that it’s good enough to be able to build something with a binary version of the very same thing. For example: gradle needs gradle and groovy to be built, groovy needs gradle and groovy to be built. So you are encouraged to take their binaries and use those to build binaries — that you already have, so what is the point of building new binaries again...? Whenever we have to bootstrap language environments we try hard to find ways that do not require trust to be placed in binary blobs. >> Building a full non-trivial Java application from source without >> resorting to some black box jars along the way is very difficult. I’m >> still working on slowly packaging the dependencies of log4j, one jar >> at a time, ... and I even forgot why I’m working on log4j because the >> dependency graph for an arbitrary Java package is overwhelmingly >> large. > > I'm not sure I would refer to Maven Central binaries as "black box". The > jars on Maven Central are digitally signed by the distributors and the > source jars are available beside them, with meta data such as license > and homepages available in the pom file. We have the sources, so we should be able to build the binaries. If we cannot do that then the sources are really just unreliable/untrustworthy documentation. There is no clear relationship between published sources and published binaries. Users have no way of making this connection. They have to trust that these binaries correspond to the published sources. We shouldn’t *have* to trust. > It should not be difficult to set up Maven and Ivy to only use a > GUIX-hosted repository (many organisations do this), or a local > repository, but it will involve an incredible amount of effort to > actually *rebuild* everything, as you are discovering. You can continue to use Maven or any other repository. But for Guix packages we will just download binary artifacts. We don’t do this for any other language either (e.g. we don’t just download Ruby gems from rubygems.org). If people really want to use those artifacts they can just continue to use “mvn” or “gem”. Guix won’t stop them from doing this. But like any other GNU distribution the packages we provide will not use pre-built binary artifacts. ~~ Ricardo