Hi Ian, Ian Eure <i...@retrospec.tv> writes:
[...] > 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. As you can see, you are not alone :-). > 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? I still like the option to leave a handcrafted channels.scm alone; I don't think this imperative variant will be obsolete in the future; it's still useful to experiment quickly, avoiding costly reconfigure just to change some bits about a new offload machine. > 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. The activation is just a script, so if it's useful to check the current value, it should be OK to do so. > 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. Yes, it'd be nice to have a uniform approach. The acl file could benefit from the same treatment, I believe (that, and 'guix authorize' should validate that we're not adding the same key multiple times -- warn something along "key XXXX is already authorized". -- Thanks, Maxim
