From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: bug#36855: guix system switch-generation doesn't Date: Thu, 08 Aug 2019 09:40:30 -0700 Message-ID: <87h86ry5j5.fsf@gmail.com> References: <7BE8190F-A8E9-454E-8F37-FBFE42FBDE10@vllmrt.net> <87zhkkojfv.fsf@dustycloud.org> <877e7on3zd.fsf@sdf.lonestar.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:54928) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvlSz-00048D-EG for guix-devel@gnu.org; Thu, 08 Aug 2019 12:40:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hvlSx-0006V8-At for guix-devel@gnu.org; Thu, 08 Aug 2019 12:40:41 -0400 Received: from mail-pl1-x642.google.com ([2607:f8b0:4864:20::642]:45688) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hvlSx-0006TX-2x for guix-devel@gnu.org; Thu, 08 Aug 2019 12:40:39 -0400 Received: by mail-pl1-x642.google.com with SMTP id y8so1648846plr.12 for ; Thu, 08 Aug 2019 09:40:38 -0700 (PDT) In-Reply-To: <877e7on3zd.fsf@sdf.lonestar.org> (Jakob L. Kreuze's message of "Wed, 07 Aug 2019 15:57:10 -0400") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: "Jakob L. Kreuze" Cc: guix-devel@gnu.org, 36855@debbugs.gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jakob, zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) writes: > 'switch-to-system-generation' doesn't call out to > 'upgrade-shepherd-services'. I'm not sure if this was an intentional > decision or not It is intentional, but only because there is currently no way to call upgrade-shepherd-services when switching system generations. Consider the procedure upgrade-shepherd-services: you must pass it an record. When you are flipping from one generation to another, how do you get the record that was used for the generation you're switching to? Guix doesn't currently store the operating system configuration file or its record anywhere, so we can't call upgrade-shepherd-services. This was discussed in 2016 and we agreed we need to persist some information to enable us to handle Shepherd services correctly. This is what Ludo suggested at the time: https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00173.html "Maybe we could store in the system output (result of =E2=80=98guix system build=E2=80=99) an sexp representation of (part of) our records: (shepherd-service (provisions (x y z)) (requirements (a b c)) (start-script "/gnu/store/=E2=80=A6-start-foo.scm") (stop-script "/gnu/store/=E2=80=A6-stop-foo.scm") =E2=80=A6) Then =E2=80=98upgrade-shepherd-services=E2=80=99 could start from this simp= lified representation instead of using the full-blown objects, and thus could work both when instantiating a new generation and when rolling back." Until that happens, you'll always have to reboot to complete the switch. FYI, last I checked (about 3 years ago), in NixOS they took a slightly different approach: instead of storing state describing the previous system generation and relying on the current system's logic to correctly parse it and use it to revert the system to a prior configuration, they just dump everything into a self-contained script that knows how to update the entire system to one specific configuration. That approach is nice in some ways because switching generations is dead simple - you just run the switching script belonging to the generation you want to switch to - but it also has downsides. For example, if the target generation is old enough compared to the current system, then the target generation's old switching script might not understand how to deal with the current system correctly. Instead, if you only store the bare minimum of state required to take the right actions, and you implement the meat of the logic in the current Guix installation, you are more likely to be able to switch generations even to very old ones where the world was very different, since the current Guix can be taught how to deal gracefully with the old world. But it seems more complicated. It's all about trade-offs. That said, I've never gone back to implement this. If you want to give it a try, you're more than welcome to do so! =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAl1MUH4ACgkQ3UCaFdgi Rp3y+hAAsKd93p6eAbVyYpZ/RFPBv47+yxJ3Lu0vmYNzch9MeZtlpNpyhQLeLvtw 7qUCxxB9Lht1gveqRnuqByXjV8aIHXpflMdoV8TF0nfEShFNbYGaN2ZDgKURNxiz 9Cpa8Oso7OsQ33HhJVSIn8vK00yZXH7bRyoGZeWrHW/G4mUKVv+R05qcBx9SmJY8 Aa94WEi5ei5XQYj43YHHctb/W91b7/eNoXQf61pdBVFVDUc/Q/5w3eG6p5Ywq7OT DAaW5klERz5xqanx78KxBblDIh3TjQgo28MCeVJMAeHThOMSKrh2v0iBy/ORaVeD ckzIsdmviVutbBYjVOdphn2uvAjqXc1zFiQ1ypFB8P6+qOZuxQFJr/sGIvFtKZ1M fqz027obBpIa8iVWBYQg5xgmoL/qkEiw8x5/aVVbxm2P7cpmh6pNn3UV65uZ5wM/ sGabloJcYwR45S/IAdZ69xdbqeltR3JPaFiS5Yj1kDvXzXewv/gxypGaVGZn2py6 119Db0JqB5nlZU6kdpGHOriNPy1kRLjb77B7JFprBhESfDmNZToF0/emDPpJyOkA Q9fvNhsjuqkOWSrbjDMG7HvV9MWsvVBPTnbDgO1Oq7GJdXl1W0dyzsxeWSgCb18L Vbj7WhWYqIVOfeZ5jayscze9tD5ZE6UI50Gx1MHDCwWrUd7GuHA= =iNTf -----END PGP SIGNATURE----- --=-=-=--