all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ian Eure <ian@retrospec.tv>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: 72686@debbugs.gnu.org, guix-devel <guix-devel@gnu.org>
Subject: Re: bug#72686: Impossible to remove all offload machines
Date: Sat, 14 Sep 2024 20:53:22 -0700	[thread overview]
Message-ID: <87ldzt606c.fsf@meson> (raw)
In-Reply-To: <87plp560ji.fsf@meson>

Hi Maxim,

Ian Eure <ian@retrospec.tv> writes:

> 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


  reply	other threads:[~2024-09-15  3:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-17 16:40 Impossible to remove all offload machines Ian Eure
2024-09-14 14:55 ` bug#72686: " Maxim Cournoyer
2024-09-15  3:24   ` Ian Eure
2024-09-15  3:53     ` Ian Eure [this message]
2024-09-15 19:06       ` Tomas Volf
2024-09-19  0:35         ` Ian Eure
2024-09-22  2:26     ` Maxim Cournoyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ldzt606c.fsf@meson \
    --to=ian@retrospec.tv \
    --cc=72686@debbugs.gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.