From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: some questions about GUIX Date: Tue, 29 Dec 2015 16:00:04 +0100 Message-ID: <87a8ot47wr.fsf@gnu.org> References: <87d1ttmdbd.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59275) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDvky-0000AK-89 for help-guix@gnu.org; Tue, 29 Dec 2015 10:00:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDvku-0004gb-53 for help-guix@gnu.org; Tue, 29 Dec 2015 10:00:12 -0500 In-Reply-To: <87d1ttmdbd.fsf@gmail.com> (Sam Halliday's message of "Sat, 26 Dec 2015 15:36:54 +0000") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org To: Sam Halliday Cc: help-guix@gnu.org Hi, Sam Halliday 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=E2=80=99 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 =E2=80=98guix import=E2=80=99 to simplify the initial import, and =E2= =80=98guix refresh=E2=80=99 to simplify subsequent updates: http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-import.ht= ml http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-refresh.h= tml So far it works well, but we have only small subsets of Hackage, CPAN, etc. It=E2=80=99s not clear to me how well that will scale, especially with large repositories with a lot of churn such as Hackage. There=E2=80=99s always the possibility to do something fully automatic. However, to me, part of the job of distro developers is to do some =E2=80=9Ceditorial work=E2=80=9D 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=E2=80=99t think there=E2=80=99ll be an =E2=80=9Cofficial=E2=80=9D pre= sence 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=E2=80=99s 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=E2=80=99s 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=3D8386 > * 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=E2=80= =99t 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=E2=80=99s easy to create custom system image from whatever GuixSD declar= ation you want and then =E2=80=98guix system disk-image=E2=80=99: https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-system.h= tml In fact, the system on the installation image is a regular declaration: https://www.gnu.org/software/guix/manual/html_node/System-Installation.ht= ml#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=E2=80=99s 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=E2=80=99.