From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 01 09:51:42 2022 Received: (at 55898) by debbugs.gnu.org; 1 Sep 2022 13:51:42 +0000 Received: from localhost ([127.0.0.1]:41663 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oTkbd-0001j9-Sd for submit@debbugs.gnu.org; Thu, 01 Sep 2022 09:51:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oTkbc-0001iv-2h for 55898@debbugs.gnu.org; Thu, 01 Sep 2022 09:51:40 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52490) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oTkbW-0007zJ-Am; Thu, 01 Sep 2022 09:51:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=D5Zen6tSvJFnNYnNd+ifTYfYMzlgv7Wkhw+9kmriALA=; b=dM9Oumn+zqMEgkdlkVcw Kj4wX20A0po+/E/cHZYPVwQ2JMlht4XnC+2ZGk2xGgd9MY2Zgu88FefzQiXot8lxT1/+q40mkDcYj s+IVtYEVuh2YQJNvdCM2vu1KSP3xhgoxB6AxM0KcodH+iN9wnSwKuNl68ywtRk+Jh876jjBfeKf9/ y1uG6n8wqZ4Z/l2IcaFsOI3HPv0Ml/uUzkAZ8ZhX2bIGEX2XxEr88DLxo6eT0H/ixz7k0hg4NUIbU A/80tDeaWlT2rlX+Zfg8JAbUxt282ufoklzXUpqxoRygh9+i3Fbp25fOrs22HmNGQCjGSwIX1CHDb sFbY0quhQQcV7A==; Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=43860 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oTkbV-0004N9-OA; Thu, 01 Sep 2022 09:51:34 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Maxim Cournoyer Subject: Re: bug#55898: Services depending on new Shepherd features may fail until reboot References: <87a6ajg2zv.fsf@gmail.com> <5521716772922285f7c6bc381c82613026eebbd9.camel@telenet.be> <87bkuvdoe4.fsf@gmail.com> <87r13ex7nw.fsf_-_@gmail.com> <87mtdl2a7u.fsf_-_@gmail.com> <87ilo9294m.fsf@gmail.com> <87a693pjm7.fsf_-_@gnu.org> <87r12fqf6j.fsf@gmail.com> <87y1v75fo0.fsf@gnu.org> <8735debvz7.fsf@gmail.com> <878rn6423p.fsf@gnu.org> <87tu5r8c8m.fsf@gmail.com> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Quintidi 15 Fructidor an 230 de la =?utf-8?Q?R=C3=A9?= =?utf-8?Q?volution=2C?= jour de la Truite X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Thu, 01 Sep 2022 15:51:31 +0200 In-Reply-To: <87tu5r8c8m.fsf@gmail.com> (Maxim Cournoyer's message of "Thu, 01 Sep 2022 09:18:01 -0400") Message-ID: <87fshb2of0.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55898 Cc: Maxime Devos , 55898@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Howdy! Maxim Cournoyer skribis: > 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. Hmm I see. > 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: > > The x, y and z services won't be started until the next reboot, as they > require a newer Shepherd version. > > Instead of seeing the new services fail to run without (for the end > user) without any obvious reason. Currently, new services don=E2=80=99t fail to run: we arrange so that new services always =E2=80=9Cwork=E2=80=9D, whether they=E2=80=99re talking to = an old shepherd or a new one. The user experience (bugs aside) should be good: services are always reloaded. IIUC, in the model you propose, we=E2=80=99d sacrifice this, by admitting t= hat in some cases we just won=E2=80=99t load services live and instead tell use= rs to reboot; the benefit would be cleaner service code. It=E2=80=99s a tradeoff; the cost/benefit ratio is not obvious to me. Thanks for explaining! Ludo=E2=80=99.