Re: [GSoC] Guix + Hurd continuation

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

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

Another can of worms I forgot to mention is <hurd/paths.h>, which
assumes that translators live in /hurd, whereas we’ll rather have them
in /gnu/store/…/hurd.

The recipe for the ‘hurd’ package could change those file names in
<hurd/paths.h>.  However, translator file names such as “/hurd/symlink”
serve as shortcuts to avoid starting a translator for each symlink:
<http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/libdiskfs/file-set-trans.c#n111>.

Thus, with /gnu/store file names for translators, a libc that uses
/gnu/store/XYZ/hurd/symlink as _HURD_SYMLINK (e.g., in
<http://git.savannah.gnu.org/cgit/hurd/glibc.git/tree/sysdeps/mach/hurd/symlink.c>)
would prevent the shortcut if it talks to a translator that expects
/gnu/store/ABC/hurd/symlink.

I think it would work anyway, but would end up starting one instance of
/hurd/symlink for each symlink, which is suboptimal.

Food for thought!

Ludo’.