GNU bug report logs - #76698
Activations interfere with each other modules

Previous Next

Full log

Message #17 received at 76698 <at> debbugs.gnu.org (full text, mbox):

From: Tomas Volf <~@wolfsden.cz>
To: Hilton Chain <hako <at> ultrarare.space>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 76698 <at> debbugs.gnu.org
Subject: Re: bug#76698: Activations interfere with each other modules
Date: Sun, 09 Mar 2025 12:38:51 +0100

[Message part 1 (text/plain, inline)]

Hilton Chain <hako <at> 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 (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.