Re: some questions about GUIX

[ludo@gnu.org (Ludovic Courtès)]

Hi,

Sam Halliday <sam.halliday@gmail.com> skribis:

> * Integration with existing software distribution managers

[...]

> How are you planning on handling these more modern languages that manage
> their own dependencies?

Currently, we import those languages’ dependency trees into the Guix
dependency tree, and so some additional QA (make sure tests pass,
provide adequate licensing info, descriptions and synopses, etc.)  We
have ‘guix import’ to simplify the initial import, and ‘guix refresh’ to
simplify subsequent updates:

  http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-import.html
  http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-refresh.html

So far it works well, but we have only small subsets of Hackage, CPAN,
etc.

It’s not clear to me how well that will scale, especially with large
repositories with a lot of churn such as Hackage.

There’s always the possibility to do something fully automatic.
However, to me, part of the job of distro developers is to do some
“editorial work” and QA as described above.

> * Docker image
>
> Most GNU / Linux distributions have uploaded a base image of their OS to
> hub.docker.com will you be creating and uploading a similar image? I'd
> love to try one out.

I don’t think there’ll be an “official” presence there, but everyone is
welcome to do it.

> I use docker to maintain a consistent build environment (across many
> heterogenous devices) for many of my free software projects and it is
> incredibly well suited to this task.
>
> I strongly recommend docker as a way to build artefacts. With the
> immergence of lightweight CI build tools such as
> http://github.com/drone/drone/ it would be an incredible way to boost
> your build farm! Indeed, you wouldn't need to ask for hardware donations
> and could instead ask for docker worker donations (users open up an SSL
> connection to their hardware and you use it from an orchestrated drone).
> It also makes it a lot easier for users to test their packaging scripts
> before submitting their changes to your central repository.

Guix’s build daemon uses containers to perform isolated builds:

  http://www.gnu.org/software/guix/manual/html_node/Features.html

So at the lower level, it’s comparable to Docker.  However, by
integrating package management and container provisioning, Guix
inherently provides more fine grain control over what goes into
containers.  Containers are also provisioned from pure declarations, as
opposed to Dockerfiles which describe sequences of commands to obtain
the desired container state.

On that topic, see also the new container features in Guix:

  https://savannah.gnu.org/forum/forum.php?forum_id=8386

> * Issue tracker / comm channels

[...]

> Will you be continuing to use debbugs, savannah and mailing lists going
> forward or would you consider moving to a modern community management
> system like gitlab?

I hear the appeal of GitLab and the like.  However, as was recently
discussed on guix-devel, while I think we must find ways to improve our
workflows (for instance, tracking patches is becoming tricky), I don’t
see us moving to one of those web-based approaches for several reasons:

  https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00429.html

> * Custom / full install images
>
> Debian and co use an antiquated concept of CD/DVD isos for
> installations. The vast majority of modern users want to put either a
> full or a custom (where they have selected all the packages)
> installation image onto a USB. It is not always possible to use network
> installation from a minimal image due to firewall rules or connectivity
> issues.
>
> Something I've wanted for a long time would be the ability to create an
> installation image on a USB, and fill the remainder of the USB with a
> VFAT partition. This is remarkably hard to achieve with gparted and a
> fixed size installation image.

It’s easy to create custom system image from whatever GuixSD declaration
you want and then ‘guix system disk-image’:

  https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-system.html

In fact, the system on the installation image is a regular declaration:

  https://www.gnu.org/software/guix/manual/html_node/System-Installation.html#Building-the-Installation-Image
  http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/install.scm#n325

The basics are in place to build customized images.  What’s missing is
convenient command-line interfaces to build specific variants.  For
example, building a live system for a USB image where /home is mounted
from a second partition of the USB disk can easily be done, but not from
the command-line.

Your contribution is welcome to help identify and fix those issues!  :-)

Thanks for your thoughtful questions.

Ludo’.