all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: Sam Halliday <sam.halliday@gmail.com>
Cc: help-guix@gnu.org
Subject: Re: some questions about GUIX
Date: Thu, 31 Dec 2015 10:50:56 +0100	[thread overview]
Message-ID: <87ziwr9can.fsf@elephly.net> (raw)
In-Reply-To: <87si2k25hu.fsf@gmail.com>


Sam Halliday <sam.halliday@gmail.com> 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

  reply	other threads:[~2015-12-31  9:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-26 15:36 some questions about GUIX Sam Halliday
2015-12-29 15:00 ` Ludovic Courtès
2015-12-29 15:40   ` Sam Halliday
2015-12-29 19:11     ` Ricardo Wurmus
2015-12-29 19:46       ` Leo Famulari
2015-12-29 23:10       ` Ludovic Courtès
2015-12-29 23:35       ` Sam Halliday
2015-12-31  9:50         ` Ricardo Wurmus [this message]
2015-12-30 13:36       ` Sam Halliday
2015-12-31  2:02         ` Leo Famulari
2015-12-31  2:17           ` Leo Famulari
2015-12-31 12:46           ` Sam Halliday
2016-01-01 14:45             ` Ludovic Courtès
2015-12-31  9:30         ` Ricardo Wurmus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ziwr9can.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=help-guix@gnu.org \
    --cc=sam.halliday@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.