Hi Maxim,
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
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.
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?