Hi Maxim,
Maxim Cournoyer <maxim.courno...@gmail.com> writes:
Hi Ian,
Ian Eure <i...@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
