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

[Maxime Devos]

On 01-09-2022 15:18, Maxim Cournoyer wrote:

> I had something different on mind; I was thinking of some added field to
> our shepherd-service object where the minimal version of Shepherd
> required could be specified, e.g. "0.9.1".
>
> The check could be abstracted in the shepherd-service implementation,
> avoiding services writers to handle that by themselves in*each*  service
> requiring so.
>
> The benefit would be an improved user experience, and cleaner service
> code.  Upon reconfiguring a machine not yet equipped with a new enough
> Shepherd, Shepherd could print:
>
> --8<---------------cut here---------------start------------->8---
> The x, y and z services won't be started until the next reboot, as they
> require a newer Shepherd version.
> --8<---------------cut here---------------end--------------->8---
>
> Instead of seeing the new services fail to run without (for the end
> user) without any obvious reason.
>
> Does that make sense?
I like this system, it's declarative, simple and doesn't have the 
defined?-looks-in-(current-module) problem. It also avoids accumulating 
compatibility fallbacks that probably won't be well-tested.

If something like (defined? 'whatever) is desired instead of version 
checks (though I don't see the value here, see Maxim explanation on 
different contexts), a similar system based on feature checks could be 
used instead:

(require-exports ; <-- the field
  '(((module name) this that ...)
    [...]))

The (if (defined? ...) preferred compat) pattern could be preserved for 
the case where a patch author puts in some extra effort to not require 
reboots on systems where an old shepherd is running, but a simple 
version check or feature check would be accepted too.

Greetings,
Maxime.

OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature