Re: some questions about GUIX

[Sam Halliday <sam.halliday@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4068 bytes --]

Leo Famulari writes:
> Our goal is to build everything from source.

OK, that helps me to understand why you are doing things the way you are
doing it.

Indeed, this means that your efforts are incompatible with my original
hope: that guix would make packaging of Java applications significantly
easier.

As a Java / Scala developer, I avoid all repackaged jars unless they
contain a bug or security fix. I don't see why I should trust a package
manager (and their machines), who are self-confessed non-experts, more
than the original author of that library, who has GPG signed their
artefacts and made their source code available.


> 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.

In that case, I strongly encourage you and other GUIX contributors to
halt all Java packaging efforts immediately.

Please dedicate time to scope out what you're planning to do: have
discussions with experienced Java developers. Find a common ground so
that the jar artefact packaging is compatible with developer needs.

It is most important that this is done properly from the beginning,
because the longer you go down this route, the more time you will have
ultimately wasted, and the harder it will be to dig yourself out of it.

From what I've seen, you're solving a problem at the expense of
excluding everybody who would use it.

One thing I can see that would be compatible would be if you rebuilt
everything as Maven artefacts, using a postfix to the versions such as
-guix, and when packages are installed they get placed into exactly the
location one would expect a maven artefact to go.

This would allow the "GUIX build" world to co-exist with the developer's
"Maven Central" world. Build tool plugins may then arise that would
transparently swap between the two at the developer's request, thereby
greatly simplifying your repackaging effort.


> Postfixing the binary name sounds like a last-ditch attempt to keep
> track of binary artifacts that have no clear provenance

It would be GUIX demonstrating that the artefacts are not the same
artefacts that Java developers expect to receive from Maven Central,
(GPG signed by the author). It doesn't hurt you to do it this way, but
it will be appreciated by all Java developers.


> 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.
>
> [2]
> http://www.vitavonni.de/blog/201504/2015042601-big-data-toolchains-are-a-security-risk.html

I agree that Maven Central needs a distributed verification mechanism.
It was designed for an era where trusting the developer's artefacts
(through GPG) was enough. (The article appears to be confused on this
matter, and fails to recognise that Maven Central artefacts are, in
fact, GPG signed, checksummed and transmitted securely over HTTPS)



I am unsubscribing from this mailing list now as I only came on to ask
these questions, and I feel I have received an answer already, thank you
all for answering!

I will leave by encouraging GUIX to move towards a more user-focused
infrastructure than mailing lists, as it is extremely difficult for
people like myself who want to dip in and out to get involved.
Therefore, I do not feel it is the right time for me to move to GUIX
just yet. A clone of github, meeting all the FSF's ethical hosting
guidelines, is absolutely essential, and I hope it is a strategic goal
of GNU.

If GUIX are planning to dedicate a significant amount of effort to
rebuilding the entire Java universe from scratch, I would prefer that
you not support Java at all (except by providing OpenJDK builds).
Instead, put that effort into building a github-like community portal.
Once GUIX proves the viability of reproducible builds, Java will catch
up.


-- 
Best regards,
Sam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 180 bytes --]