Hilton Chain <hako@ultrarare.space> writes: > On Sat, 08 Mar 2025 05:29:51 +0800, > Tomas Volf wrote: >> >> > but unfortunately (gnu build activation) and (guix build utils) are >> > implicit dependencies. This is hard to change at the moment. >> >> I do not think this is true. When I look at the activation script for >> my service, I do not see any additional code then my service has. So >> assuming it would be executed, instead of loaded, (guix build utils) >> should not be in the environment. Am I missing something? > > (gnu build activation) and (guix build utils) are added to the environment > before loading activation scripts, existing activation services may depend on > this. For example firmware-service-type uses ‘activate-firmware’ directly > without importing (gnu build activation).
I am not sure I follow. When I have an activation service looking like: --8<---------------cut here---------------start------------->8--- #~(mkdir "/x") --8<---------------cut here---------------end--------------->8--- The generated file looks like the following: --8<---------------cut here---------------start------------->8--- #!/gnu/store/ylwk2vn18dkzkj0nxq2h4vjzhz17bm7c-guile-3.0.9/bin/guile --no-auto-compile !# (mkdir "/x") --8<---------------cut here---------------end--------------->8--- Wait... When I looked again I have now noticed that your patch actually modifies the activation-script procedure to explicitly add the modules. It did not do that before. That is a shame. Would it not be better to just add the appropriate use-modules into the services that are missing them? I am not sure these two modules being available is documented anywhere, so in-tree users can be fixed, and out-of-tree users are relying on something they should not assume (so they should be fixed as well, possibly with some deprecation period). > >> > I have sent a patch which might partially address your issue: >> > >> > [PATCH v2 3/3] services: activation: Continue on exceptions. >> > https://issues.guix.gnu.org/73494#26 >> > >> > It executes activation scripts by ‘invoke’, so they won't change the >> > environment. >> > >> > What I'm trying to achieve is to avoid blocking the activation process >> > when one >> > script fails. >> >> Well, that patch would probably resolve my issues, correct. What I am >> unsure about is whether ignoring errors is a good idea and what (if any) >> impact it will have on the rest of the deploy process. Like, if the >> activation fails, would it not be better to rollback instead of push >> forward? Dunno, I probably just do not know enough about this. :) > > Makes sense, but too late at this stage since it's already switched to the new > generation before activation. > > The current behavior is, one failed activation breaks the whole activation > process, without a clear indication. As a result, all services depending on > activation may fail. And I want to limit failed services to relevant > ones. I see. Makes sense, thanks for explanation. Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
signature.asc
Description: PGP signature
