Re: some questions about GUIX

[Leo Famulari <leo@famulari.name>]

On Wed, Dec 30, 2015 at 01:36:12PM +0000, Sam Halliday wrote:
> Hi Ricardo,
> 
> I have a few more questions about your proposed jar packaging.
> 

> Ricardo Wurmus writes:
> > We are building library for library as individual packages in Guix. We
> > certainly won’t bundle prebuilt jars from Maven if it can be avoided
> > at all.
> 
> Does this mean that you have a GUIX package for every jar? If so, can
> you have multiple versions of the same jar installed at the same time?
> Support for multiple versions of a library will be necessary as it is
> not always a simple case of bumping the version to use a library: many
> libraries introduce breaking changes at both source and binary level.

Yes, we can have multiple versions of every library installed at the
same time, and users of those libraries are linked to a specific library
at build time.

Our goal is to build everything from source. We even build documentation
such as manpages and PDFs from source wherever possible.

And if upstream software distributors do not clearly specify which
versions of dependent libraries are compatible, instead choosing to
bundle binary artifacts of those libraries without providing
instructions for rebuilding from source, I'd call that a security risk
and affront to users' freedom.

> 
> Will you be using the same version names as the official upstream
> binaries? I strongly recommend against doing this. The convention in
> corporate environments is that rebuilds of jars incur a postfix to their
> version. E.g. a rebuild of guava 18.0 (even with no changes to the
> sources) would be 18.0-guix1. Of course, there is no way for you to know
> that jars are not being loaded by name at runtime through the
> classloader, so you introduce further opportunity for bugs here.

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.

I can say that we are actively working towards being able to
reproducibly build all the software we package, and so "postfixing" the
version for a new build of the same source is unnecessary once we have
established that a particular code base can be built reproducibly. In
fact, in Guix, trying to rebuild the same source code will only start an
actual compilation if the GNU store [0] does not include the memoized
output of the last build.

Postfixing the binary name sounds like a last-ditch attempt to keep
track of binary artifacts that have no clear provenance, using build
systems and distribution methods that do not empower [1] downstream
users to build software from source.

If you find Guix interesting but somewhat confusing, I recommend you
spend some time learning more about it, and please keep asking
questions! You may find Guix a breath of fresh air after wondering if
"guava-18.0-guix1" included that one special platform-specific bug fix
or tweak, or if it was "guava-18.0-guix2" ;)

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.

[0]
https://www.gnu.org/software/guix/manual/html_node/The-Store.html

[1]
In some cases it is so difficult that it may as well be closed source.
Free software (or open-source, as the license may be) in name only, if
you ask me.

[2]
http://www.vitavonni.de/blog/201504/2015042601-big-data-toolchains-are-a-security-risk.html

> 
> 
> -- 
> Best regards,
> Sam