GNU bug report logs -
#72686
Impossible to remove all offload machines
Previous Next
Full log
Message #11 received at 72686 <at> debbugs.gnu.org (full text, mbox):
Hi Maxim,
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
> Hi Ian,
>
> Ian Eure <ian <at> 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.
>
As I was putting together a patch for this, I realized there’s a
problem: if a user is *manually* managing either
/etc/guix/machines.scm or channels.scm, these files would be
deleted, which likely isn’t what they want. The current code lets
users choose to manage these files manually or declaritively, and
there’s no way to know if the files on disk are the result of a
previous system generation or a user’s creation. Since the
channel management is a relatively new feature, I suspect there
are quite a few folks with manually-managed channels that this
would negatively impact. I know there was some disruption just
moving to declaritive management of channels (but I can’t find the
thread/s at the moment).
I don’t see an elegant technical solution to this. I think the
best option is probably to say that those files should *always* be
managed through operating-system, and put a fat warning in the
channel news to update your config if they’re still handled
manually.
The only other option I can see would be to keep the existing
filenames for user configuration, and declaritively manage
different files -- like declaritive-channels.scm. This comes with
its own set of problems, like needing to update the Guix daemon to
read and combine multiple files; and the inability to know whether
a given `channels.scm' is declaritively- or manually-managed means
a bumpy upgrade path (ex. should this preexisting channels.scm
file be left as-is, or renamed to the new name?)
I’m inclined to go with the fat-warning option, but am also
thinking this likely needs some guix-devel discussion.
What do you think?
Thanks,
— Ian
This bug report was last modified 166 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.