Hi Maxim,
Ian Eure <ian@retrospec.tv> writes:
Toggle quote (122 lines)
> 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?
>
Disregard this, I continued thinking after sending the email (as
one does) and realized that any managed file will be a link into
the store -- so if the system is reconfigured with no
build-machines or channels *and* the corresponding file is a store
link, it should be removed; otherwise, it should remain untouched.
I can work with this.
Thanks,
— Ian
