From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Re: Thoughts on making Guix even better Date: Sun, 08 Mar 2020 21:54:31 +0100 Message-ID: <87o8t68t4o.fsf@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:50235) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jB2wT-0006w3-E4 for guix-devel@gnu.org; Sun, 08 Mar 2020 16:54:34 -0400 In-Reply-To: (Raghav Gururajan's message of "Sun, 23 Feb 2020 02:49:12 +0000") 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-mx.org@gnu.org Sender: "Guix-devel" To: Raghav Gururajan Cc: guix-devel@gnu.org Hi, "Raghav Gururajan" skribis: > The guix system transactions are NON-MODULAR. That is, you cannot selecti= vely reconfigure certain parts of the system. For example, you either recon= figure the system as a whole (or) you do not reconfigure the system at all. > > IMPLICATIONS: > > Lets assume we have 5 packages in profile. Package 1, 3 and 5 has non-cri= tical updates. Package 4 has non-critical update but it breaks. Package 2 h= as critical update (CVE). We can either upgrade all packages except package= 4 (or) we can upgrade only package 2. > > Lets assume we have 5 services/packages in system. Package/Service 1, 3 a= nd 5 has non-critical updates. Package/Service 4 has non-critical update bu= t it breaks. Package/Service 2 has critical update (CVE). Now, when we reco= nfigure the system, all packages/services will upgrade, package/service 4 w= ill break the system. We can of course do '--roll-back' and take the system= to previous working state. But that will leave the system with critical vu= lnerability. Therefore, we cannot reconfigure package/service 2 or any othe= r parts of the system, until the package/service 4 is fixed. This window/ga= p puts guix system at great risk and instability. On one hand, I agree that it=E2=80=99d be nice to be able to update just pa= rts of the system, like you explain. On the other hand, that would lead to an unknown and possibly unreproducible system state, which defeats what declarative (=E2=80=9Cnon-modular=E2=80=9D) system upgrades bring. Besides, I don=E2=80=99t see how one could introduce this =E2=80=9Cimperati= ve=E2=80=9D approach at the system level, technically. All in all, it would be best if the situations that make =E2=80=9Cmodular s= ystem upgrades=E2=80=9D appear necessary didn=E2=80=99t occur in the first place. Thoughts? Ludo=E2=80=99.