Re: Guix on Debian (was: GSoC ideas)

[Leo Famulari]

On Tue, Feb 23, 2016 at 03:52:30PM -0800, Christopher Allan Webber wrote:
> Diane Trout writes:
> 
> >> That looks like the way forward to me. Such a package can setup and
> >> start the daemon - which is enough. No need to get the blessing from
> >> the distributions themselves (will take time, but it will come -
> >> there
> >> really is no difference with allowing foreign packages to work
> >> anyway).
> >
> >
> > I wrote a basic Debian recipe to build guix, create the build users,
> > and install the systemd config file.
> >
> > https://github.com/detrout/debian-guix
> >
> > Currently I've only split the guix package into the emacs components
> > and everything else. I'd thought about splitting the daemon out into
> > its own package, but I wasn't sure what the daemon depended on.
> >
> > The daemon is still using the default /gnu/store path, and the user
> > needs to manually run guix authorize if they want to use hydra
> > binaries. The package is currently based on the stable 0.9.0 release,
> > and I'm not sure how security updates make it into a guix store if you
> > without updating the scheme packaging source tree.
> >
> > It might be nice to prompt the user if they wanted to authorize hydra
> > on install but that's not implemented.
> >
> > Currently its unlikely to go into Debian because Debian policy requires
> > everything to be built from source, and currently the Guix build
> > process downloads some bootstrap binaries.
> >
> > However with the current packaging "guix environment --pure bash --
> > bash" does give me a clean guix environment, and the guix info docs get
> > installed when Debian emacs can see them.
> >
> > Diane
> 
> Great work Diane!
> 
> Are those bootstrapping binaries really necessary for getting Guix
> going?  I guess for some reason I thought if you did the whole
> configure/make/etc dance it wouldn't be but maybe I'm wrong.

My understanding is that if you alter the bootstrap binaries, the entire
dependency graph will change, forcing a rebuild of everything. And of
course, the altered binaries may present different interfaces, breaking
things as well.