Hi Maxim,
Maxim Cournoyer <maxim.courno...@gmail.com> writes:
Hi Ian,
Ian Eure <i...@retrospec.tv> writes:
[...]
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'd think that be a great option to pursue, although it's more
work more
thoughts. Perhaps it could work along these lines
(brainstorming)
I like the idea to leave the original, potentially manually
written file
in place and complement it with a declarative counterpart. The
same
would also have benefited /etc/guix/acl, which suffers from the
same
ambiguity.
Apologies for the silence, life stuff has been eating most of my
free time, but I have a bit of bandwidth to spend on this problem
again.
I took a swing at this, it wasn’t as difficult as I expected.
While this approach gives a smooth upgrade path for those who’ve
configured channels in a stateful way switching to declarative
configuration, it’s possibly bumpy for those already using a
declarative config. If a machine with declarative channels is
reconfigured, the channels will be duplicated from
/etc/guix/channels.scm to /etc/guix/channels-declarative.scm.
Using `delete-duplicates' on the merged channels should avoid
major problems, but I think it still needs a loud entry in news
and manual action (deleting /etc/guix/channels.scm) to upgrade.
Given that both approaches will require manual action, I’m a bit
inclined to go with the simpler, and take over the existing file.
That said, I think the failure mode of the simpler approach
(stomping on channels a user may have configured) is undeniably
worse than potentially duplicating channels or continuing to pull
in old ones unexpectedly. Do either of you have a strong opinion
or more information which would help guide this decision?
The root issue at work behind all these problems is that
activation code only sees the desired target config, rather than
the current and target configs. Comparing the current and target
configs would allow the code to more precisely compute the needd
change to move from one state to the next. I think that could be
a good change to make, though it’s obviously going to be much more
involved, and IMO will require discussion outside the scope of
this specific bug.
I have a draft patch series I hope to send up soon, but need to
get Guix System up in a VM to test first. It does separate
declarative channels into their own config, but doesn’t do the
same for build machines. While I think many fewer users configure
build machines than channels, it’s probably a good idea to use the
same approach for both channels and machines.
— Ian
