bug#55898: Services depending on new Shepherd features may fail until reboot

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>> Yes.  The issue is that we’re more free-style than systemd: we’re
>> basically loading code live in the running Shepherd.  So we have to
>> write that code such that it works with older Shepherd versions.
>>
>> This is why we have things like conditions on
>>
>>   (defined? 'make-inetd-constructor)
>>
>> and the likes, with a fallback.
>
> I saw that used somewhere, but I still think a minimally required
> Shepherd version field could be of use on services, for the following
> reasons:
>
> 1. Otherwise each services are left implementing ad-hoc solutions.
>
> 2. It's more complicated to be compatible with two Shepherd version than
> simply mentioning the minimum version required, and prevent the service
> from running until it is satisfied (especially on a system like Guix
> System where we *know* what is the current version of Shepherd
> available).

I think it’s a situation similar to “feature tests vs. identity tests”
in build system configuration (checking whether the libc function you
want to use is available rather than checking whether ‘uname’ returns
“Linux”), and for the same reason I tend to prefer feature tests as
shown above.

I won’t pretend it’s pretty :-), but I don’t see an improvement feasible
in the short term.

In the long term, maybe we’d want the service API in the Shepherd to be
more declarative, more like packages in Guix.  But that’s more for a 2.0
horizon IMO.

Perhaps we should close this issue unless it becomes actionable?

Thanks,
Ludo’.