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)