[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#30948: [PATCH core-updates] guix: Reap finished child processes in b
From: |
Ludovic Courtès |
Subject: |
bug#30948: [PATCH core-updates] guix: Reap finished child processes in build containers. |
Date: |
Sat, 26 Nov 2022 16:11:12 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Hi,
Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>> My view is just that this mechanism belongs in “user code”, not in the
>> low-level mechanisms such as ‘build-expression->derivation’ and
>> ‘gexp->derivation’. It’s a matter of separation of concerns.
>
> Why? On my Guix System, such signal handling is handled by Shepherd, if
> I'm not mistaken. As I user, I can trust the foundation to be sane,
> rather than having to provide the bits to make it so myself.
>
>> Of course we don’t want to duplicate that code every time, but the way
>> we should factorize it, IMO, is by putting it in a “normal” module that
>> people will use.
>>
>> Putting it in gnu-build-system is an admittedly hacky but easy way to
>> have it widely shared.
>
> I think we can do better than hacky here :-)
I think the real issue here is semantic clarity when it comes to
derivation inputs.
If I write:
(gexp->derivation "foo" #~(mkdir #$output))
I can be sure that my derivation depends on nothing but (default-guile).
This is important for tests, but also to make sure we can use this
primitive everywhere—if it pulled in the Shepherd, I wouldn’t be able to
use to build glibc, because there’d be a cycle.
In that sense, having child-reaping code in gnu-build-system.scm, just
like in (guix least-authority), doesn’t seem unreasonable to me.
That said, I’m open to other proposals so please unleash your
creativity! :-)
We’re touching core components though so this will require discussion.
Ludo’.