Hi Ludovic, Ludovic Courtès <[email protected]> writes:
> Hi, > > Maxim Cournoyer <[email protected]> skribis: > >> Ludovic Courtès <[email protected]> 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. 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. > 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? It's a relatively narrow use case and it's relatively rare too, but I'd err on keeping it open until it gets fixed, whether in a definitive fashion or as a more limited one to help users facing 3. above. Thanks, and welcome back! Maxim
