[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: some questions about GUIX

From: Ricardo Wurmus
Subject: Re: some questions about GUIX
Date: Thu, 31 Dec 2015 10:50:56 +0100
User-agent: mu4e 0.9.13; emacs 24.5.1

Sam Halliday <address@hidden> 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  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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]