Hi, Ludovic Courtès <[email protected]> writes:
> Hi Maxim, > > Maxim Cournoyer <[email protected]> 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
