Re: some questions about GUIX

[Leo Famulari]

On Wed, Dec 30, 2015 at 09:02:53PM -0500, Leo Famulari wrote:
> 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" ;)

I have to make another point about this. I work with a lot of people who
are not computer programmers. Most of their work is collaborating on
"office" type documents and slideshows. They are constantly wondering if
the right document is "reportDONE", "reportDONEFINAL", "report-FINAL2", etc.
It makes me so sad, knowing the tools we have for source code management
like git and mercurial, and how these tools have empowered us to work so
much more effectively and efficiently than before.

Hopefully you see the analogue ;) I promise you we aren't totally crazy.

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