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

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi,

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

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Agreed, but the context differs wildly: while Autoconf or browsers for
>> example really are facing a diversity of configuration, the version of
>> Shepherd used in Guix System is known and controlled.  So the only
>> problems bound to happen are in this context:
>>
>> 1. New Shepherd version introduced in Guix (package upgrade).
>>
>> 2. New Shepherd features used by services.
>>
>> 3. Machine reconfigured using a commit including 1 and 2.
>>
>> The problems are temporary: upon a reboot the running Shepherd version
>> will be the latest, and have all the features needed.
>>
>> Hence my suggestion to use something simple to improve the user
>> experience of a user faced with 3.
>
> So are you suggesting replacing:
>
>   (defined? 'make-inetd-constructor)
>
> by something like:
>
>   (version<? shepherd-version "0.9.0")
>
> or is it something different that you have in mind?

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?

Thanks,

Maxim