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 KHIGI+xvfGACDgEAgWs5BA (envelope-from ) for ; Sun, 18 Apr 2021 19:44:12 +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 2IqsHexvfGDcfAAAbx9fmQ (envelope-from ) for ; Sun, 18 Apr 2021 17:44:12 +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 EFD531A18A for ; Sun, 18 Apr 2021 19:44:10 +0200 (CEST) Received: from localhost ([::1]:58902 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lYBSs-0005Ne-6M for larch@yhetil.org; Sun, 18 Apr 2021 13:44:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53410) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYBSk-0005NV-N9 for bug-guix@gnu.org; Sun, 18 Apr 2021 13:44:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:36161) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lYBSk-0001cx-Fa for bug-guix@gnu.org; Sun, 18 Apr 2021 13:44:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lYBSk-00052J-CR for bug-guix@gnu.org; Sun, 18 Apr 2021 13:44:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#47846: Feature Request: Add ability to disable having cache or generations Resent-From: bo0od Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sun, 18 Apr 2021 17:44: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: Maxime Devos , 47846@debbugs.gnu.org Received: via spool by 47846-submit@debbugs.gnu.org id=B47846.161876780419299 (code B ref 47846); Sun, 18 Apr 2021 17:44:02 +0000 Received: (at 47846) by debbugs.gnu.org; 18 Apr 2021 17:43:24 +0000 Received: from localhost ([127.0.0.1]:47707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYBS6-00051C-Oa for submit@debbugs.gnu.org; Sun, 18 Apr 2021 13:43:23 -0400 Received: from mx1.riseup.net ([198.252.153.129]:35454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYBS0-00050q-2N for 47846@debbugs.gnu.org; Sun, 18 Apr 2021 13:43:20 -0400 Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4FNcjp2XvjzDqMf; Sun, 18 Apr 2021 10:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1618767790; bh=2jNIoIfZVxGcYBFFpD5FP4hMra1SEKgIunpqKXwyDhA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=PgdcDsiS/L6i7Qdc+Q5Xt6pMmdmBMy4cwrE39z/WWJBTTjHh3M4cgqbDTdxe/279l SJpt9S8PYCghc92HL9toPKp+UQuuc8XLx6x55QWa/YQ0p+Od9qNy7bJkz/xjx2l6tu MtLxtUDuvgdrqoh5RgMLqIWML9yai6YYZ+ju28eg= X-Riseup-User-ID: 59009A4188FF16CA27568AA9700B64795411F4E4D6D5CA1BD1AEB66C94E72084 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4FNcjm6MCRz1yBT; Sun, 18 Apr 2021 10:43:08 -0700 (PDT) References: <726ce75bd7bb4424703c608b0c51a6c8eb6a2662.camel@telenet.be> From: bo0od Message-ID: Date: Sun, 18 Apr 2021 17:43:04 +0000 MIME-Version: 1.0 In-Reply-To: <726ce75bd7bb4424703c608b0c51a6c8eb6a2662.camel@telenet.be> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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=1618767851; 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: content-transfer-encoding:content-transfer-encoding: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=1lKwTTcZVLnXrAPNK/LFf8gloc8OglSu4yXSCX8EHhw=; b=eUbruW7xMGrATbWYGbrCcudPbRjJk26lnDTXyNK7R8M6q8Q5yjDAJ0Gola+kMqEYA2ECzg 1CH67ybGAVJJkt7l11U1EihxeHzwGbArp7PpkINBMgZfyFPC5l/R+vLkucVaysz/gcsfYS 672oODetm9dN4wI+dWsOpKfq/3pWA3Kfhlm7wQh/EtGO7xemRavRa8JIxb3jR4lg62uwwg bdWKDB/3653ZuBN2pXKg7ljLiM4BuB/rvsVBozvYQix0Yl7V4VY0kv+q3lRlYP4CyW7UKo YUaUOH0OMvm47bgPJSRhz7O6LjSsecYiisZ+yMuLaItRXA6rp86aWjj+w2VobQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1618767851; a=rsa-sha256; cv=none; b=N6tW1MDFm7imYZak1LLPGRJD34JvUlWOCdA+33mJFMxJixF83yJwBUMf+77P5binWR7Myk M3Z31kXrs/roHpZit2wxgSxyGf98PO50KLbL1LeKETcuvB4/ucHXuD7P71sejsJMCUPbb3 OSXU0hx38QvqPuiYKE630O4PPws2wVAK+8SL0AeQovCIkvlEdE5suGDdHGl7Fx9NHHuWZF uWPD8ncpIRCKXtWvycQZjizzmM4O51D1q2+4R+CDtbCHLsnN6PgC+Z7HdQzqnrZaGx58k7 iIjLBSPejW1gRDAWXWBJ3J6T+BUBmOMtMrWHGN8UZcEjBGSZe3SjhgXCaztzWQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=riseup.net header.s=squak header.b=PgdcDsiS; 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: -1.34 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=riseup.net header.s=squak header.b=PgdcDsiS; dmarc=fail reason="SPF not aligned (relaxed)" header.from=riseup.net (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: EFD531A18A X-Spam-Score: -1.34 X-Migadu-Scanner: scn0.migadu.com X-TUID: kTDD7V1BOFx1 > There isn't really any caching Im calling the saved old versions of software cache, So if there is better term to use good. > * P1 is kept around in case the user isn't satisfied, or is feeling nastolgic > or something Yeah this is what im suggesting to have ability to disable this behavior as an optional choice for the user (not by default). > In case of user packages, old generations are also saved. Yeah no more "old" anything, Just latest fresh only. > 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 I have VM total is 29GB it goes as 20GB for guix system and 9GB swap = nightmare of space (other distros this is more than enough specially main/known one debian,fedora,trisquel/ubuntu...etc). > 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 ‘Bloating the disk size’), this seems harmless. Yeah not suitable for low space usages specially like mobile phones or limited storage like VMs/VPS. So this is more of annoying thing to have thus suggesting to have ability to disable it. > 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 disconnect first. Hmm not really always effective as guix system is as well targeting servers so as (might be in the future) can be targeting mobile phones both of them hard to keep internet off. But i got my answer to the question from leo famulari which is these packages doesnt have access to suid and thats the important part. > Yes, but let's at least keep the last few generations around. Yeah this is optional for each user case, The default is that guix keeping it anyway but if someone want to disable it he should be able to do so and use guix just for getting latest software available. > So this would have to be run when there's only 10% disk space left or something like that. actually i get only 0.something left when upgrading guix on 20GB, So without running the commands just no upgrades. > When you've the space, I recommend keeping the ‘old stuff’ around. > You'd never know whether you'll need it later! In case you'll need it later[..] Thats true but not always you are able to have more space easily, Sometimes you are limited with payment if you are working on remote VPS/VM or using devices which are hard/expensive changing their hard like mobiles/tablets. This issue doesnt talk about my own case scenario but as any other user which might have similar circumstances and guix without this suggested feature wont help these users. > 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. Anything which can overcome the problem of having limited disk space. > 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 previous > version whenever possible could be possible, but I'm not sure it's worth it. Any method not a problem since this feature going to be optional side feature anyway. Create the suitable way of doing it and i will test and report back if there is any problems. > Of course, what you decide to hack on, what approaches you'll take, etc. > is up to you! So when i open feature request ticket i should answer myself and do it? No, I want this from upstream to be implemented as a feature its not about me only but any scenario which has the same problem because guix doesnt give solutions for limited space (and 20GB is not small storage for GNU/Linux distro) Maxime Devos: > bo0od schreef op za 17-04-2021 om 18:29 [+0000]: >> Hi There, >> >> Current situation with the guix distro upgrade is:(as i understand) >> >> A) User Packages: whenever there is an upgrade to package A version 1 to >> new Version lets call it A version 2 , So the process is ADD A2 → SWITCH >> to A2 → 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 versions > & 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 version > 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 nastolgic > 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: >> >> - 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 ‘Bloating the disk size’), this seems 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 disconnect > first. > > Only run old (and therefore possibly with publicly-known and unfixed security > 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 since). > >> As it depend if they >> have access to suid or not (i didnt investigate this, but if they have >> then thats big problem but this is not the ticket to discuss it) > > "guix package -i" never creates setuid/setgid binaries. The only setuid/setgid > binaries that guix creates are in /run/setuid-programs. These are setuid/setgid > _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 >> its useful and....i know that but like i said might be not suiting all >> 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 boot > 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: >> >> 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 errors > 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 ‘old stuff’ around. > You'd never know whether you'll need it later! In case you'll need it later, > keeping the ‘old stuff’ around saves on Internet traffic (saving 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 >> 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 than >> having the latest packages available in the distro). >> >> So the process is ADD A2 → SWITCH to A2 → Delete A1 , Or Download A2 → >> 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 previous > 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 >