[bug#61750] [PATCH] gnu: shepherd: Build Shepherd from git.

[Attila Lendvai <attila@lendvai.name>]

> Apologies. I’m not convinced about the patch, mainly because I’ve been
> using Shepherd as a channel for testing, which I think makes fine
> details about the ‘shepherd’ package in Guix less interesting.
> 
> For info on how to do that, see:
> 
> https://git.savannah.gnu.org/cgit/shepherd.git/tree/README
> 
> The added bonus when doing this is that ‘guix system describe’ tells you
> precisely which Shepherd commit you’re using.
> 
> WDYT?


ouch, we've been here before, sorry for my loss of memory!

but after having read the README once again, i'm still not sure how this would work. please confirm my assumption:

if i add shepherd as a channel, then i unavoidably need to issue a `guix pull` (slow!) before i can test any shepherd changes, even if the channel points to a local checkout. also, i need to record any pending changes that i want to test into a git commit.

this is my objective:
 - be able to edit files in a shepherd checkout
 - issue a command that runs a vm with my shepherd changes included
 - keep this cycle reasonably fast to avoid frustration

my ultimate objective:

fix a shepherd-action bug that doesn't manifest in my `guix system vm` tests, only when i pull stuff to my server (slow!). i have zero info on what goes wrong besides a non-zero return code from tar that my action invokes. to gain more info i'm planning to add extensive logging to shepherd, especially around its fork+exec-command calls.

this is how i used to hack shepherd, when i need to test it in its real environment:

i have a guix system test that i have extracted from the guix test suite. it defines an OPERATING-SYSTEM object that is run using `guix system vm`:

https://github.com/attila-lendvai/guix-crypto/blob/main/tests/swarm-tests.scm

a custom shepherd package is defined for this OS object by modifying its SHEPHERD-ROOT-SERVICE-TYPE.

my custom shepherd package inherits from the shepherd package from guix, and replaces its source to point to my own shepherd checkout. for this to work, my local guix contains the patch to compile shepherd from git.

this worked fine, but something broke my setup recently. it was that some heavy packages started to depend on shepherd, which means that if i include my patch to compile shepherd from git, then all those packages need to be recompiled locally, which is pohibitively slow (it's added to the edit-compile-run cycle).

a tangential: i think these new dependencies are only needed for the CLI tools provided by the shepherd package. splitting shepherd into two packages (CLI tools and service) would also resolve this problem of mine.

possible solutions:
 1) i learn some better way to hack on shepherd

 2) shepherd in guix is compiled from git, so that i can easily inherit from it

 3) i give up on getting this merged, and try to keep a completely standalone shepherd package in sync with what's in guix. i also give up on adding detailed instructions to the docs on how to hack on shepherd (https://issues.guix.gnu.org/54199).

i'd appreciate some guidance on how to proceed from here. i don't want to waste anyone's time further with this. if this change is not welcome in guix proper, then reject the patch and i'll try to find another way (probably option 3) to achieve my goals.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Think what you do when you run in debt; you give to another power over your liberty.”
	— Benjamin Franklin (1706–1790), 'The Way to Wealth' (1758)