From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sam Halliday Subject: Re: some questions about GUIX Date: Tue, 29 Dec 2015 23:35:09 +0000 Message-ID: <87si2k25hu.fsf@gmail.com> References: <87d1ttmdbd.fsf@gmail.com> <87a8ot47wr.fsf@gnu.org> <87vb7h1cwh.fsf@gmail.com> <87a8otax38.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39911) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aE3nR-00048h-Oq for help-guix@gnu.org; Tue, 29 Dec 2015 18:35:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aE3nO-0008Pa-GO for help-guix@gnu.org; Tue, 29 Dec 2015 18:35:17 -0500 In-Reply-To: <87a8otax38.fsf@elephly.net> 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: Ricardo Wurmus Cc: help-guix@gnu.org --=-=-= Content-Type: text/plain Thanks Ricardo, --=-=-= Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --==-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ricardo Wurmus writes: > I=E2=80=99m not sure I understand what you mean here. I have been packagi= ng 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=E2=80=99t 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. > Building a full non-trivial Java application from source without > resorting to some black box jars along the way is very difficult. I=E2=80= =99m > still working on slowly packaging the dependencies of log4j, one jar > at a time, ... and I even forgot why I=E2=80=99m 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. 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. What practical benefit does rebuilding on the GUIX farm actually bring? Is there a claim that the binary build can be traced directly to a "trusted" machine and source code? In the Scala community, there is an attempt to rebuild a range of free software projects as part of the continuous integration of the scala compiler itself: https://github.com/scala/community-builds It may be worthwhile collaborating with the authors in order to avoid duplicating efforts. > We are building library for library as individual packages in Guix. We > certainly won=E2=80=99t bundle prebuilt jars from Maven if it can be avoi= ded > at all. As a Java / Scala developer, I consider the maven / ivy dependency tracking to be the environment where I define the exact and definitive versions of dependencies that I require and I would not be happy depending on the GUIX-SD jars. Although, I would not object to using GUIX-SD jars as a user, if the installation was easier than self-managed and I did not experience and bugs as a result of the re-packaging. I would be very interested if you had a way of integrating with Maven Central artefacts in order to install applications, as it would make it significantly easier for me, as a developer, to produce packages for GUIX-SD. =2D-=20 Best regards, Sam --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlaDGK0ACgkQh5Q4qVL9G8nhkgCeJTzTNmJ00Ozco97ZULbbYdVi auMAniS3j6lFvV4+hnyBkBdB6D/i+XND =+Cfb -----END PGP SIGNATURE----- --==-=-=-- --=-=-=--