From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id GL25Aj5Ae2BiEAAAgWs5BA (envelope-from ) for ; Sat, 17 Apr 2021 22:08:30 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id GJPtOT1Ae2CQUgAAbx9fmQ (envelope-from ) for ; Sat, 17 Apr 2021 20:08:29 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 6BD9BE3E3 for ; Sat, 17 Apr 2021 22:08:29 +0200 (CEST) Received: from localhost ([::1]:36368 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lXrEy-0005TV-Je for larch@yhetil.org; Sat, 17 Apr 2021 16:08:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43456) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lXrEZ-0005T9-AV for bug-guix@gnu.org; Sat, 17 Apr 2021 16:08:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:33192) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lXrEZ-0006Zk-3L for bug-guix@gnu.org; Sat, 17 Apr 2021 16:08:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lXrEY-0001ne-V6 for bug-guix@gnu.org; Sat, 17 Apr 2021 16:08:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#47846: Feature Request: Add ability to disable having cache or generations Resent-From: Maxime Devos Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 17 Apr 2021 20:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47846 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: bo0od , 47846@debbugs.gnu.org Received: via spool by 47846-submit@debbugs.gnu.org id=B47846.16186900756897 (code B ref 47846); Sat, 17 Apr 2021 20:08:02 +0000 Received: (at 47846) by debbugs.gnu.org; 17 Apr 2021 20:07:55 +0000 Received: from localhost ([127.0.0.1]:44737 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXrER-0001nB-5t for submit@debbugs.gnu.org; Sat, 17 Apr 2021 16:07:55 -0400 Received: from baptiste.telenet-ops.be ([195.130.132.51]:58896) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXrEP-0001n2-HI for 47846@debbugs.gnu.org; Sat, 17 Apr 2021 16:07:54 -0400 Received: from ptr-bvsjgyjmffd7q9timvx.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:aaf1:9810:a0b8:a55d]) by baptiste.telenet-ops.be with bizsmtp id tw7r2400K0mfAB401w7rwq; Sat, 17 Apr 2021 22:07:52 +0200 Message-ID: <726ce75bd7bb4424703c608b0c51a6c8eb6a2662.camel@telenet.be> From: Maxime Devos Date: Sat, 17 Apr 2021 22:07:33 +0200 In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-6F/sLjW6bkzLiZjTxboC" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r21; t=1618690072; bh=idpkaY/iymUSUihJ42Z9JvtfQKxrV3CifcoBPBC1hQg=; h=Subject:From:To:Date:In-Reply-To:References; b=WX1MaKUPiwgsX7SHOoaUdN5oqN18Xy8ttJCAyzE09/y2DOh3ZVUC1JYQa4ivzQ2KY pDxczSdZTpzc3VIYlFOaDcyKVTptpkQVk2e8RApznZnBAgZYH19gWrpW8hTZJPCE6U 6S/8J7UOTXsWLJJSgiTQ3SVK75EQpQqs0T7PascC+K2TzcAA2cmOPCAhjfdb64/jNv p1+ib8Dz819z/e1uSTeJ+vWSdAp8rHk/F3joxxXbNvpqwHgA3LU6sqOfiTd55WTRBJ jvu4/rWa+N4Ag7BskJbjeCR8pnpappGU8CC0G2NFQLtTJIzRWr2V55/FtMhnOLG2n5 jilwzd2H5wZUA== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1618690109; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=idpkaY/iymUSUihJ42Z9JvtfQKxrV3CifcoBPBC1hQg=; b=Vjm/okLByV3wHHT0eCohHDZqnxLu6cwnQVgdWcs+5UXlRhnio9p6nPJTVzsp4ZmD8CawS5 4fVAnUoW2Pr8FMhfiYSyXrEX5NMVCXmdkfzqYU6kCsj5TvpBf2/7CcHDTcsXTryhlDlO3R /+/yS4gZMQ+0RKPNd2a91UPS2T0CEvS4d7bsRoZzXpJNs8cX3X2tLtEFD70CgVcTOdlVmO kl76LjBFCTVHptaWg9PxP/rqujfR8mFRmYzssyA+SoUm/MX2GFViJ2e3KTKRdsR1MFO8+q UmRglwguH5CzwGZefrfIukG6lRjgaXwxLA98z6fa/JxLfrKH35eMbn1T2WW9fg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1618690109; a=rsa-sha256; cv=none; b=TbAkNr7s4+byN6GzUO6yZimI/cFo/sZo6a4SWviYmtdcoqHoqRSXGsBk7MDer9bhze3kI1 8+G+S+p3CBlhh8hexPcwlXyU84OHIYKSiuB4dN6yxcNPXys7NLKnZi8U38SLBzY65mx8gw gjPRevd+SSPAOCzSafCWNxKNlZywPQANQ2BR5WjSYNgMlBd4LrCLlIYBonfZjjvsqPbY8C NBOMF76g9gY/ZwN2r1ATBTAXSziq+aqbMaNvSqFFsNpl9cTeiHHiZ43GxGMD4msm/O3B/X AC1fFWoNThjGmumxaKdj9uq4sVj6zeSLCUwUZNMeStTfbz0rv+WzaTLgArPnrA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=telenet.be header.s=r21 header.b=WX1MaKUP; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Spam-Score: -3.44 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=telenet.be header.s=r21 header.b=WX1MaKUP; dmarc=fail reason="SPF not aligned (relaxed)" header.from=telenet.be (policy=none); spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Queue-Id: 6BD9BE3E3 X-Spam-Score: -3.44 X-Migadu-Scanner: scn0.migadu.com X-TUID: CABxJnI0JFK5 --=-6F/sLjW6bkzLiZjTxboC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable bo0od schreef op za 17-04-2021 om 18:29 [+0000]: > Hi There, >=20 > Current situation with the guix distro upgrade is:(as i understand) >=20 > A) User Packages: whenever there is an upgrade to package A version 1 to= =20 > new Version lets call it A version 2 , So the process is ADD A2 =E2=86=92= SWITCH=20 > to A2 =E2=86=92 Cache A1 and so on. There isn't really any caching, it's more like garbage collection like in Guile, other Schemes & lisps, Java, ..., where old objects (package version= s & profiles that aren't referred anywhere anymore) are deleted. Is that informative for you? When the user upgrades A from version A1 to version A2, creating a new vers= ion of the profile P2: * P1: original profile, referring to the binaries of A1 (and other packages, which I'll ignore here) * The user asks guix to upgrade from A1 to A2. So guix first builds A2. * Guix creates a profile P2, referring to the binaries of A2 * P2 becomes the current profile. * P1 is kept around in case the user isn't satisfied, or is feeling nasto= lgic or something > B) System Packages: Same process but it will be saved through generations In case of user packages, old generations are also saved. Try "guix package --list-generations". I have 128 generations of bloat. Lemme update ("guix package -u"), soon I'll have 129 generations of bloat. So the bloat is even worse, and your point is even more compelling! > This causes unpleasant actions to some users: >=20 > - Bloating the disk size About 200 GiB or so in my case, though admittedly that's partially because I never run "guix gc" or that command for deleting old generations > - Having old unnecessary files/packages Well, having ... They are just sitting there under /gnu/store. A user won't accidentally see them or something. Aside from taking in disk space (see =E2=80=98Bloating the disk size=E2=80=99), this s= eems harmless. > - Questionable security of the saved old versions. As long as you don't run the old versions, you should be fine. If you actually run the old versions, then you'll get the old packages with old security bugs. If they can connect to the network, best disconnec= t first. Only run old (and therefore possibly with publicly-known and unfixed securi= ty issues) issues on trusted data! Use case I have in mind: /.../old-profile-version/bin/tome4 (when you've disabled Internet access= , for trying an old version of tome4 (a game) to see what has changes sin= ce). > As it depend if they=20 > have access to suid or not (i didnt investigate this, but if they have= =20 > then thats big problem but this is not the ticket to discuss it) "guix package -i" never creates setuid/setgid binaries. The only setuid/se= tgid binaries that guix creates are in /run/setuid-programs. These are setuid/s= etgid _copies_ of what's requested in the _current_ (or the one at boot, I forgot= ) operating-system declaration. > I know someone would jump in and say but roll back is great feature and= =20 > its useful and....i know that but like i said might be not suiting all= =20 > users (specially with limited space). Yes, but let's at least keep the last few generations around. E.g., I actually _almost_ never use the rollback mechanism. The only time was when I messed up the operating-system declaration, so I had to boo= t into the previous system generation (is that the term?). Of course, then there's a choice to make for _how many_ generations to keep around ... > Current manual solution is to delete this extra mess using 2 commands: >=20 > guix gc -d 1s && sudo guix system delete-generation You should run them in the opposite order. Also, "guix package --delete-generations" should be run for each user. > This should be run whenever there is no space left, Tricky ... reportedly, many software does not handle out-of-disk-space erro= rs well. Also, letting "guix gc" and "guix package --delete-generations" run takes some time. So this would have to be run when there's only 10% disk space left or something like that. > Or to get rid of the old stuff When you've the space, I recommend keeping the =E2=80=98old stuff=E2=80=99 = around. You'd never know whether you'll need it later! In case you'll need it late= r, keeping the =E2=80=98old stuff=E2=80=99 around saves on Internet traffic (s= aving some time) (lessening the load on the substitute servers -> less network and disk I/O = and CPU usage --> less monetary costs, less environmental cost). > My suggestion is to have the ability to make Guix automatically just=20 > having the latest up to date packages There's an unattended-upgrade-service for the system profile (if that's the result of operating-system). Maybe we can have something similar for user profiles. > without extra consumed storage (no cache no generation no nothing more th= an > having the latest packages available in the distro). >=20 > So the process is ADD A2 =E2=86=92 SWITCH to A2 =E2=86=92 Delete A1 , Or = Download A2 =E2=86=92=20 > Replace over A1 and so on. This in-place replacement you seem to be suggesting, is rather counter one = of the primary goals of Guix (and Nix, for that matter) --- functional package management. Automatically deleting the previous profile and trying to delete the previo= us version whenever possible could be possible, but I'm not sure it's worth it= . You could try to implement it yourself, and try your modified guix out for a while, and report whether it seems to work well, of course! However, I believe the following would be easier in the short term (and *very* likely to be accepted upstream): Implement a graphical application (maybe using the guile-gnome bindings, or as a web app run on localhost) that has a few buttons for collecting garbage and deleting old profiles. Guix could use some graphical stuff. Of course, what you decide to hack on, what approaches you'll take, etc. is up to you! Greetings, Maxime --=-6F/sLjW6bkzLiZjTxboC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYHtABhccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7hdpAQDpT0cbRTPo0Fv+XGkZQwV+VPut 8JSENjE2XPAZMj20kAD/ZpcZkYef/y1PdJiUPT+ujueTH3VRausjBTwIZYIIQwY= =e9fp -----END PGP SIGNATURE----- --=-6F/sLjW6bkzLiZjTxboC--