GNU bug report logs - #30948
[PATCH core-updates] guix: Reap finished child processes in build containers.

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 30948 <at> debbugs.gnu.org, Carlo Zancanaro <carlo <at> zancanaro.id.au>
Subject: bug#30948: [PATCH core-updates] guix: Reap finished child processes in build containers.
Date: Sat, 26 Nov 2022 16:11:12 +0100

Hi,

Maxim Cournoyer <maxim.cournoyer <at> 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’.

Previous Next

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