[bug#54199] [PATCH] doc: Add 'Working on Shepherd' section.

[Maxime Devos <maximedevos@telenet.be>]

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

Attila Lendvai schreef op ma 28-02-2022 om 19:51 [+0100]:
> +Luckily, not all changes to Shepherd require the recompilation of all
> +its dependencies.  The rule of thumb here is that:

‘not all changes require’ -> ‘most changes do not require’?

> +@itemize
> +
> +@item
> +if you are making changes to the public API of Shepherd (i.e. anything
> +that may have compile-time effects on dependant packages, like adding or
> +removing public functions, or changing public macros, etc.), then you
> +will need to go through a full recompilation, so that the the Guix
> +codebase, and the dependant packages can observe the changes while they
> +are being compiled.

I don't think this is necessary?  If I change the API a little, then
why would packages only using 'sbin/halt', 'sbin/reboot' and
'sbin/shutdown' of the 'shepherd' package have to be recompiled?

Even if the API is changed, the package still uses the old shepherd
package with the old API, so no recompilation necessary.

Also, even if the API is changed, then 'guix system reconfigure ...'
would pick up the modified shepherd, and shepherd services modules
would be compiled against the shepherd from the shepherd-configuration
record (see 'shepherd-boot-gexp', 'shepherd-configuration-file' and
'scm->go' in (gnu services shepherd)).

> +@item
> +if you're only working on Shepherd's implementation (e.g. making
> +Shepherd's error handling more bullet proof), then it's enough to only
> +recompile Shepherd itself, and use the resulting package as the one that
> +gets started as the init process.
> +

So I don't think the distinction between API and implementation is
necessary here.  (Feel free to correct in you have observed the
contrary!)

Greetings,
Maxime

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