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 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.
