workflow while hacking on Shepherd

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)

Re: workflow while hacking on Shepherd

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

Attila Lendvai schreef op di 01-03-2022 om 07:59 [+0000]:
> 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

AFAICT, these two use the same shepherd -- i.e., the shepherd from
the 'shepherd-configuration' record.

To see what shepherd the 'start' and 'stop' procedures are compiled
against, and what 'shepherd' is actually used at boot, see (gnu
services shepherd) (they are the same!).

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: workflow while hacking on Shepherd

[Attila Lendvai]

> > 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
>
> AFAICT, these two use the same shepherd -- i.e., the shepherd from
> the 'shepherd-configuration' record.
>
> To see what shepherd the 'start' and 'stop' procedures are compiled
> against, and what 'shepherd' is actually used at boot, see (gnu
> services shepherd) (they are the same!).


FTR, this is indeed the case.

thanks for the clarification!

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
Toleration is not about believing that stupid people are intelligent, it's about letting stupid people be victims of their own stupidity rather than being victims of yours.

Re: workflow while hacking on Shepherd

[Oliver Propst]

On 2022-03-01 08:59, Attila Lendvai wrote:

Hi Attlila thanks for working on this. For me your proposal seems to 
make sense (but I guess input from more folks would be needed).

-- 
Kinds regards Oliver Propst
https://twitter.com/Opropst

Re: workflow while hacking on Shepherd

[Ludovic Courtès]

Hi!

The Shepherd is decoupled from Guix.  In general, when hacking on it,
you should think of it as an independent piece of software, a user of
which is Guix.

A corollary is that there are well-defined interfaces between the two.
Usually, you cannot add a new interface in the Shepherd an expect to use
it right away in Guix System.

In particular, when running ‘guix system reconfigure’, you have to keep
in mind that the last step, which injects new services (or service
replacements) into the running PID 1, is potentially talking to an old
shepherd that does not implement the latest and greatest
interfaces—think of a machine that hasn’t been rebooted in ages.

That said, it’s often useful to test Shepherd changes in Guix System, of
course.  To do that, you can modify the ‘shepherd’ field of
<shepherd-configuration> so that it points to your local package
variant.

I’m afraid I’m not really answering your questions, but I hope it makes
some kind of sense.  :-)

Thanks,
Ludo’.