[GSoC] Guix + Hurd continuation

[Ludovic Courtès]

Hello!

Now that Manolis managed to produce the bootstrap binaries (yay!), we
must plan for what’s next.

I think the first thing will be to try and start building things
natively, as noted in
<https://www.gnu.org/software/guix/manual/html_node/Porting.html>.  That
implies a few things:

  0. Run Guix’s ‘./configure --with-courage && make’ and see what
     happens.

  1. ‘guix-daemon’ must work correctly on GNU/Hurd.  This should be
     mostly the case, but it’s degraded compared to GNU/Linux because it
     will not use name spaces and bind mounts, so no chroot either (see
     
<http://git.savannah.gnu.org/cgit/guix.git/tree/nix/libstore/build.cc#n54>.)
     That’s OK for a start.  Maybe there are other issues I haven’t
     thought of.

  2. When building natively, surely you’ll find out that some packages
     do not build (PATH_MAX!), and that there are assumptions in
     hurd.scm and base.scm, such as the fact that GNU/Hurd is a
     cross-compilation target and not a native system.

  3. In parallel to that, I should review wip-hurd again and apply the
     patches to a new ‘core-updates’ branch.

  4. Instead of sitting idle watching build logs ;-), it Would Be Nice™
     to implement the ‘mount’ and ‘umount’ functions for GNU/Hurd in
     libc, with support for MS_BIND using /hurd/firmlink.  See
     <http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/utils/mount.c#n213>
     (the Hurd’s ‘mount’ command) for a good starting point.

     Of course libc hacking can be quite involved.  So ideally Samuel,
     Thomas, and others would give you detailed guidance and/or hack
     power.  What do people think?

     The reason I’m suggesting this is that it will be useful for the
     build daemon (see #1), and it will also facilitate porting of
     GuixSD afterwards (see
     
<http://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/syscalls.scm#n144>.)

Anything else?  Comments?

Ludo’.