Re: Plan for a release!

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

Hi,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

>> Yes: you need to have ‘installation-os-for-gui-tests’ (or preferably a
>> variant thereof) include all the services/packages needed for the target
>> config.
>>
>> In the manual installation tests we use ‘define-os-with-source’ to both
>> embed the target OS and its references in the installation image *and*
>> have the source of the target OS available in /etc/target-config.scm in
>> the installation image.
>
> Ok! I'm testing with an installation image containing all desktop
> environments. This represents 1200 store items (image around 6GiB).
>
> The disk-image creation takes 2h45 on a powerful machine (with
> KVM). I've seen your insights on this topic here:
>
>>   I'd like to propose an alternative mechanism which would be faster and
>>   not involving virtual machines. Maybe producing the disk-image in a
>>   container?
>
> Unfortunately, I don’t think that’s possible.  The reason we resort to
> VMs is that the Linux kernel doesn’t allow you, for instance, to mount a
> file system without being root.  So doing things like running Parted,
> mounting a file system, and populating it typically requires root
> privileges.  (In some cases, there are tools like mksquashfs that can do
> that from user-space, but it’s very ad-hoc.)
>
> It makes sense and after some digging, I cannot propose something
> better (nix is using the same mechanism). However, I feel very
> frustrated by this disk-image thing, loosing a lot of time and
> computation time for some copies.

Understood.  :-/

Another approach would be to do like ‘guix system vm’, which is to share
the store with the host.  But then we would need a way to be able to run
a daemon in the guest and have its build results overlaid on top of the
host-provided store.

Note that system tests other than the installation tests actually use
the equivalent of ‘guix system vm’ already, so they copy much less stuff
around.

Thanks,
Ludo’.