workflow while hacking on Shepherd

[Attila Lendvai]

hi Guix,

following up on the thread "setting open files limit for daemon processes", and 
on Maxime's generous help, i have written up a first iteration of documentation 
at:

https://issues.guix.gnu.org/54199

i'll address the listed concerns, but until then i thought i'll propose an idea 
here that may make the workflow even slicker.

there seems to be 3 ways in which Shepherd is influencing the build results of 
Guix:

1) the code that will be run as the init process in a Guix System

2) the code that the Guix codebase is compiled against

3) the Shepherd package, on which some packages depend (i assume for stuff like 
the halt executable in its bin/ output?).

from the above list, recompiling 3) takes by far the longest time (qemu, 
inkscape, etc are down the stream).

in the current setup, it's possible to change 1) without recompiling anything 
else (see my doc patch), but changing 2) without triggering 3) does not seem to 
be possible.

it's not obvious to me what is the exact mechanism through which the Shepherd 
codebase is made available when Guix is being compiled. judging from the 
behavior, it seems to be through the shepherd package definition in 
gnu/packages/admin.scm, but i don't see where/how.

blurry proposal:

maybe we could introduce another shepherd package definition, that would be 
used in 2), but not trigger a rebuild of 3)?

i would be happy to experiment with this, but i'd appreciate some guidance 
whether this all makes sense, and if so, then where is the point in the build 
process and/or codebase that defines which Shepherd is used in 2).

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“It is impossible to begin to learn that which one thinks one already knows.”
        — Epictetus (c. 55–135 AD)