Re: bug#72686: Impossible to remove all offload machines

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Ian,

Ian Eure <ian@retrospec.tv> writes:

> Ran into this issue last week.  If you:
>
> - Configure some offload build machines in your operating-system
>  configuration.
> - Reconfigure your system.
> - Remove all offload build machines.
> - Reconfigure your system again.
>
> ...then various guix operations will still try to connect to offload
> machines, even if you reboot the affected client.
>
> This is caused by a bug in the `guix-activation' procedure:
>
>   ;; ... and /etc/guix/machines.scm.
>   #$(if (null? (guix-configuration-build-machines config))
>         #~#f
>         (guix-machines-files-installation
>          #~(list #$@(guix-configuration-build-machines
>           config))))
>
> If there are no build machines defined in the configuration, no
> operation is performed (#f is returned), which leaves the previous
> generation’s /etc/guix/machines.scm in place.
>
> The same issue appears to affect channels:
>
>   ;; ... and /etc/guix/channels.scm...
>   #$(and channels (install-channels-file channels))

Interesting!

> I’d be happy to take a stab at fixing this, but I’m not certain what
> direction to go, or how much to refactor to get there. Should the
> channels/machines files be removed (ignoring errors if they don’t
> exist)?  Should empty files be installed?  Should that happen inline
> in `guix-activation', or in another procedure? Should the filenames be
> extracted to %variables to avoid duplicating between the two places
> they’ll be used?
>
> If someone would like to provide answered, I would contribute a patch.

I guess the simplest would be to attempt to remove the files when there
are no offload machines or channels, in this already existing activation
procedure.  Extracting the file names to %variables sounds preferable
yes, if there's a logical place to store them that is easily shared.

A patch would be dandy!

-- 
Thanks,
Maxim