[bug#41350] [PATCH v2 3/3] system: vm: Build vm-image using native qemu, for the Hurd.

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

>> But maybe we can just rebase ‘system-qemu-image’ & co. on top of (gnu
>> image)?  What prevents us from doing that, Mathieu?
>>
>> If we can do that, then indeed, there’s no point in insisting on fixing
>> cross-compilation support in (gnu system vm).
>
> I think we could proceed that way:
>
> * Merge Ludo's serie on master.

I think that can wait because on IRC Janneke explained that it doesn’t
fix anything for GNU/Hurd (to my surprise).  So I’ll maybe check again
once the relevant Hurd bits are on master, instead of checking ARM
cross-compilation.

Anyway it’s much less important now that (gnu image) can be used for the
task!

> * Then we could review & merge Jan's wip-hurd-disk.

Do I get it right that we first need
<https://issues.guix.gnu.org/41560>?

The ‘wip-hurd-vm’ branch contains many things:

  1. (gnu system hurd) with the Hurd services etc.

  2. The ‘hurd’ field of <operating-system>.

  3. <menu-entry> with multiboot support.

  4. Hacks to work around vm.scm defects: uses of ‘with-parameters’,
     ‘hurd-target?’, disabling sqlite3, and #~#$ tricks.

I think part of the reason this cycle has been so long is that it’s been
kind of a big bang; big bangs are great because they lead to something
new and exciting, but they’re also intimidating.  :-) For me personally,
looking at all these aspects at once was just too much.

For merging, I think it’d be great to see #1 and #2 as a first step, and
then #3.

I do not want any of #4 :-), because I really think it could lead to
maintenance headaches down the road, which would make the kind of
changes we’re making today practically impossible in the future.

Thoughts?

Ludo’.