GNU logs - #47846, boring messages


Message sent to bug-guix@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#47846: Feature Request: Add ability to disable having cache or generations
Resent-From: bo0od <bo0od@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sat, 17 Apr 2021 18:31:01 +0000
Resent-Message-ID: <handler.47846.B.16186842085850 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 47846
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: 47846 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-guix@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.16186842085850
          (code B ref -1); Sat, 17 Apr 2021 18:31:01 +0000
Received: (at submit) by debbugs.gnu.org; 17 Apr 2021 18:30:08 +0000
Received: from localhost ([127.0.0.1]:44539 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXphn-0001Vo-UW
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 14:30:08 -0400
Received: from lists.gnu.org ([209.51.188.17]:59656)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bo0od@HIDDEN>) id 1lXphl-0001Sq-OI
 for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 14:30:06 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:56396)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <bo0od@HIDDEN>) id 1lXphl-0004SW-E2
 for bug-guix@HIDDEN; Sat, 17 Apr 2021 14:30:05 -0400
Received: from mx1.riseup.net ([198.252.153.129]:51864)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <bo0od@HIDDEN>) id 1lXphj-0006fC-K3
 for bug-guix@HIDDEN; Sat, 17 Apr 2021 14:30:04 -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 4FN1pK0PHZzDqgQ
 for <bug-guix@HIDDEN>; Sat, 17 Apr 2021 11:30:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1618684201; bh=UKIo31zBX21HDW77lOdGS3FwE99eRwrHtUh4PMa3VYE=;
 h=To:From:Subject:Date:From;
 b=lJjpI3ulfrx3MEB9QiURFRwHgh0fabxju488tBYQ+gqQp7ZiQx6soVxbVa3qe92x1
 ElrXNeliLJSvrVwFyyRELq8LLIMYMT1QE1Gw9GZSzg6XMk11icBsliWSqb2/FyogeV
 wAr9GPlFRZEhCQv9iORFm9wv/NO+aGO1wVyUeNI8=
X-Riseup-User-ID: 847BF765EE840BDEA328DE19EBCDC2863622D38AC6CDE91250F59A64F545ABA3
Received: from [127.0.0.1] (localhost [127.0.0.1])
 by fews2.riseup.net (Postfix) with ESMTPSA id 4FN1pJ1FVbz1yBT
 for <bug-guix@HIDDEN>; Sat, 17 Apr 2021 11:29:59 -0700 (PDT)
From: bo0od <bo0od@HIDDEN>
Message-ID: <df61f8dd-ca00-a419-a751-46d39b1c9f00@HIDDEN>
Date: Sat, 17 Apr 2021 18:29:56 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=198.252.153.129; envelope-from=bo0od@HIDDEN;
 helo=mx1.riseup.net
X-Spam_score_int: -12
X-Spam_score: -1.3
X-Spam_bar: -
X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_FMBLA_NEWDOM=1.5,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

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.

B) System Packages: Same process but it will be saved through generations

This causes unpleasant actions to some users:

- Bloating the disk size
- Having old unnecessary files/packages
- Questionable security of the saved old versions. 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)

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).

Current manual solution is to delete this extra mess using 2 commands:

guix gc -d 1s && sudo guix system delete-generation

This should be run whenever there is no space left, Or to get rid of the 
old stuff

My suggestion is to have the ability to make Guix automatically just 
having the latest up to date packages 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.


ThX!




Message sent:


Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: bo0od <bo0od@HIDDEN>
Subject: bug#47846: Acknowledgement (Feature Request: Add ability to
 disable having cache or generations)
Message-ID: <handler.47846.B.16186842085850.ack <at> debbugs.gnu.org>
References: <df61f8dd-ca00-a419-a751-46d39b1c9f00@HIDDEN>
X-Gnu-PR-Message: ack 47846
X-Gnu-PR-Package: guix
Reply-To: 47846 <at> debbugs.gnu.org
Date: Sat, 17 Apr 2021 18:31:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-guix@HIDDEN

If you wish to submit further information on this problem, please
send it to 47846 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
47846: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D47846
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems


Message sent to bug-guix@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#47846: Feature Request: Add ability to disable having cache or generations
Resent-From: Leo Famulari <leo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sat, 17 Apr 2021 19:25:02 +0000
Resent-Message-ID: <handler.47846.B47846.16186874892734 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 47846
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: bo0od <bo0od@HIDDEN>
Cc: 47846 <at> debbugs.gnu.org
Received: via spool by 47846-submit <at> debbugs.gnu.org id=B47846.16186874892734
          (code B ref 47846); Sat, 17 Apr 2021 19:25:02 +0000
Received: (at 47846) by debbugs.gnu.org; 17 Apr 2021 19:24:49 +0000
Received: from localhost ([127.0.0.1]:44671 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXqYj-0000i2-1Y
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:24:49 -0400
Received: from out1-smtp.messagingengine.com ([66.111.4.25]:37787)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <leo@HIDDEN>) id 1lXqYh-0000hq-MJ
 for 47846 <at> debbugs.gnu.org; Sat, 17 Apr 2021 15:24:48 -0400
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
 by mailout.nyi.internal (Postfix) with ESMTP id 991825C0143;
 Sat, 17 Apr 2021 15:24:42 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute3.internal (MEProxy); Sat, 17 Apr 2021 15:24:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=famulari.name;
 h=date:from:to:cc:subject:message-id:references:mime-version
 :content-type:in-reply-to; s=mesmtp; bh=2PRkDTfU/R3qRbGdgz/3Mzsc
 9Qxas2Qjz7gCpKL49FE=; b=iT+uN6D7q9/8+PPQy5fANEQYJpYKDdqPFhLyc04B
 yMMXJu3T5IbyqAcY+8jEkibJDw+dW9bugks1NHjjilzhZnsyWns8abR+hKcv5B5e
 GbfyJc7mv8l9aTXZkMc8qAb2ioD6t6XtYDl8K+z1aEhBx80OXBLeYeHEbMRRptTt
 mcw=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-type:date:from:in-reply-to
 :message-id:mime-version:references:subject:to:x-me-proxy
 :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=2PRkDT
 fU/R3qRbGdgz/3Mzsc9Qxas2Qjz7gCpKL49FE=; b=RHGCfPCzI6kjndDhEtfeKf
 QBssrgUY61sVJh7krHUZLgzsQVmPXKQV9f1bvCN/C96v0JK4s/BhY0a1TV8BUwv+
 5SspcU4gQydcpwpmvyUYeVVmkdeOn4TKmegdKOPkiDDDHT8Yw7rYFag/xCAPLP1H
 PQIhgHyaagJfhGEXeqOvYio3l3vSVg94vQ2+odE4LpgcFQT6GzGTCj0lc1zxVkUl
 MbJXl1XMfdxtBhFk9QmVXYyHivQEGhRpmEXmz6jOamiw1U2X5XK8WYv9EF0HVVwh
 SlaiWa1Sv3/aZmp6ucZmoaBxJz6tA+3vNMzR20/bl4qjFVY8z5/GhUm69WHKHPig
 ==
X-ME-Sender: <xms:-jV7YBkx9qb8JvEbrND5GQBy8GuSYDa44l9L8ey5al3AvuXBiR-UVA>
 <xme:-jV7YM158X8YcUE2129lZztU7HhqpIrM8yCvegHBGH1931ZRcbkR7-o32acAySPPe
 l8HokvN2dJ5J1m8xg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeliedgvdeiiecutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
 necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehttd
 ertddttddvnecuhfhrohhmpefnvghoucfhrghmuhhlrghrihcuoehlvghosehfrghmuhhl
 rghrihdrnhgrmhgvqeenucggtffrrghtthgvrhhnpeeukeektdffvddtudegjeegtdevhf
 eufeeivdejiedtieegtdevjedvjeehffevgfenucfkphepuddttddruddurdduieelrddu
 udeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheplh
 gvohesfhgrmhhulhgrrhhirdhnrghmvg
X-ME-Proxy: <xmx:-jV7YHpim3PathfzCvH8FOd1ler5b0X1tnbDzZ-3er02TiqYwthp7A>
 <xmx:-jV7YBn2_axGBBmakKH0SAkZp9WwtTeptC9oFfKSXeBYY9TYln1SPw>
 <xmx:-jV7YP0CjJw27zPkCSfu_SIyCHEZGG0pmGm9X--EAgP--xiceoK38g>
 <xmx:-jV7YEg5LNZDW0uZVi1q-GCKSewlz9mNH4-osXjixqQ6dIB15M8N0A>
Received: from localhost (pool-100-11-169-118.phlapa.fios.verizon.net
 [100.11.169.118])
 by mail.messagingengine.com (Postfix) with ESMTPA id F403824005B;
 Sat, 17 Apr 2021 15:24:41 -0400 (EDT)
Date: Sat, 17 Apr 2021 15:24:40 -0400
From: Leo Famulari <leo@HIDDEN>
Message-ID: <YHs1+LKzqfG35m12@HIDDEN>
References: <df61f8dd-ca00-a419-a751-46d39b1c9f00@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <df61f8dd-ca00-a419-a751-46d39b1c9f00@HIDDEN>
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  On Sat, Apr 17, 2021 at 06:29:56PM +0000, bo0od wrote: > -
 Questionable security of the saved old versions. As it depend if they have
 > access to suid or not (i didnt investigate this, but if they hav [...] 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [66.111.4.25 listed in list.dnswl.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
 [66.111.4.25 listed in wl.mailspike.net]
 2.0 PDS_TONAME_EQ_TOLOCAL_SHORT Short body with To: name matches
 everything in local email
 0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

On Sat, Apr 17, 2021 at 06:29:56PM +0000, bo0od wrote:
> - Questionable security of the saved old versions. 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)

They do not.




Message sent to bug-guix@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#47846: Feature Request: Add ability to disable having cache or generations
Resent-From: Leo Prikler <leo.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sat, 17 Apr 2021 20:06:01 +0000
Resent-Message-ID: <handler.47846.B47846.16186899096634 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 47846
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: bo0od <bo0od@HIDDEN>, 47846 <at> debbugs.gnu.org
Received: via spool by 47846-submit <at> debbugs.gnu.org id=B47846.16186899096634
          (code B ref 47846); Sat, 17 Apr 2021 20:06:01 +0000
Received: (at 47846) by debbugs.gnu.org; 17 Apr 2021 20:05:09 +0000
Received: from localhost ([127.0.0.1]:44725 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXrBk-0001iw-Og
	for submit <at> debbugs.gnu.org; Sat, 17 Apr 2021 16:05:09 -0400
Received: from mailrelay.tugraz.at ([129.27.2.202]:28785)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <leo.prikler@HIDDEN>) id 1lXrBi-0001il-Gy
 for 47846 <at> debbugs.gnu.org; Sat, 17 Apr 2021 16:05:07 -0400
Received: from nijino.local (194-96-9-9.adsl.highway.telekom.at [194.96.9.9])
 by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4FN3vy3N0Dz3wV3;
 Sat, 17 Apr 2021 22:05:02 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at;
 s=mailrelay; t=1618689902;
 bh=R1+CXUAwlncGJDQXs8aOkvCpnM5gWDRyzj6j3snV9z8=;
 h=Subject:From:To:Date:In-Reply-To:References;
 b=MMvRUkdVkP6CV6CVjXTnRRPQjiaeH9hsIyOY+kHSLto5U8/6drQBkI1oG1CNQcfEG
 HmwbpCWIDbBA813e5Yp+TSJxkeV9Ykqkb+Kw0taCJBZWWtV4N4RIk2ByQKiUnm3cN5
 ojiTMga4eUH3akagEvaARRxlXO7+wYafd6kXpKlQ=
Message-ID: <34dd59bee8f503432a3eea3c55dde95a23ecc7f1.camel@HIDDEN>
From: Leo Prikler <leo.prikler@HIDDEN>
Date: Sat, 17 Apr 2021 22:05:00 +0200
In-Reply-To: <df61f8dd-ca00-a419-a751-46d39b1c9f00@HIDDEN>
References: <df61f8dd-ca00-a419-a751-46d39b1c9f00@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.2 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw
X-Spam-Scanner: SpamAssassin 3.003001 
X-Spam-Score-relay: -1.9
X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Hi,
Am Samstag, den 17.04.2021, 18:29 +0000 schrieb bo0od:
> 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.
> 
> B) System Packages: Same process but it will be saved through
> generations
There is no active caching going on.  Besides potentially building
software, the process of "upgrading" one generation of your Guix
profile or system is simply the act of letting a symbolic link point
elsewhere.  Nothing more, nothing less.  Each generation is itself a
"root" in GC terms from the moment it is built.

> This causes unpleasant actions to some users:
> 
> - Bloating the disk size
That's debatable.  Now, yes, it is no secret, that Guix uses more disk
space than your traditional software, as keeps copies of your old data
around, but on a desktop with 500MB storage, you can keep several
months of that around if you want to.  Things might be a bit different
on smartphones and embedded systems, which may want to GC more often,
but it's not like minimal setups are impossible.
> - Having old unnecessary files/packages
Which is bad how?
> - Questionable security of the saved old versions. 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)
You would have to explicitly run those old, insecure versions, for them
to be an attack surface, which I'd hazard you won't unless you're still
actively using them anyway.  Note that for the case, that the mere
existence of those is a threat, you must assume your attacker to have
arbitrary shell code execution already.

> 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).
Because it is.  There are things larger than package generations.  My
current profile weighs 8.5GB according to du, much of which can be
shared between generations.  A typical anime episode encoded with x264
at 1080p weighs 1GB or more.  So one season of your favourite show is
literally more data than all of your software.

> Current manual solution is to delete this extra mess using 2
> commands:
> 
> guix gc -d 1s && sudo guix system delete-generation
> 
> This should be run whenever there is no space left, Or to get rid of
> the 
> old stuff
Just FYI deleting all that so often only puts unnecessary stress on
your disk, because native inputs will have to be redownloaded and
you're not even freeing up that much space.

> My suggestion is to have the ability to make Guix automatically just 
> having the latest up to date packages without extra consumed storage
> (no 
> cache no generation no nothing more than having the latest packages 
> available in the distro).
That's not very functional.  Again, you're putting more stress on your
hardware by actively asking it to remove stuff.

Regards,
Leo





Message sent to bug-guix@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#47846: Feature Request: Add ability to disable having cache or generations
Resent-From: Maxime Devos <maximedevos@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sat, 17 Apr 2021 20:08:02 +0000
Resent-Message-ID: <handler.47846.B47846.16186900756897 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 47846
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: bo0od <bo0od@HIDDEN>, 47846 <at> debbugs.gnu.org
Received: via spool by 47846-submit <at> 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 <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lXrER-0001nB-5t
	for submit <at> 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 <maximedevos@HIDDEN>) id 1lXrEP-0001n2-HI
 for 47846 <at> 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@HIDDEN>
From: Maxime Devos <maximedevos@HIDDEN>
Date: Sat, 17 Apr 2021 22:07:33 +0200
In-Reply-To: <df61f8dd-ca00-a419-a751-46d39b1c9f00@HIDDEN>
References: <df61f8dd-ca00-a419-a751-46d39b1c9f00@HIDDEN>
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-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)


--=-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--





Message sent to bug-guix@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#47846: Feature Request: Add ability to disable having cache or generations
Resent-From: Maxime Devos <maximedevos@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sun, 18 Apr 2021 12:14:02 +0000
Resent-Message-ID: <handler.47846.B47846.161874801526321 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 47846
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: bo0od <bo0od@HIDDEN>, 47846 <at> debbugs.gnu.org
Received: via spool by 47846-submit <at> debbugs.gnu.org id=B47846.161874801526321
          (code B ref 47846); Sun, 18 Apr 2021 12:14:02 +0000
Received: (at 47846) by debbugs.gnu.org; 18 Apr 2021 12:13:35 +0000
Received: from localhost ([127.0.0.1]:45619 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lY6Ix-0006qS-Bj
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 08:13:35 -0400
Received: from albert.telenet-ops.be ([195.130.137.90]:44512)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <maximedevos@HIDDEN>) id 1lY6Iu-0006q6-Fk
 for 47846 <at> debbugs.gnu.org; Sun, 18 Apr 2021 08:13:33 -0400
Received: from butterfly.local ([5.23.206.113])
 by albert.telenet-ops.be with bizsmtp
 id uCDV2400M2TKVvH06CDWBf; Sun, 18 Apr 2021 14:13:31 +0200
Message-ID: <c2e3738a58455079b8a90afc0079cda26ffa17f5.camel@HIDDEN>
From: Maxime Devos <maximedevos@HIDDEN>
In-Reply-To: <726ce75bd7bb4424703c608b0c51a6c8eb6a2662.camel@HIDDEN>
References: <df61f8dd-ca00-a419-a751-46d39b1c9f00@HIDDEN>
 <726ce75bd7bb4424703c608b0c51a6c8eb6a2662.camel@HIDDEN>
Content-Type: multipart/signed; micalg="pgp-sha512";
 protocol="application/pgp-signature"; boundary="=-ZvJgKHzxoMfdkoDaCPjm"
Date: Sun, 18 Apr 2021 12:00:33 +0200
MIME-Version: 1.0
User-Agent: Evolution 3.34.2 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r21;
 t=1618748011; bh=qPuFkannZ6SYBDFs8YMmB4hReO7Skr1qKS5SjCp5rH4=;
 h=Subject:From:To:In-Reply-To:References:Date;
 b=R2/MwsSgf9gBdOtlyP5jjRWlwhaNz9XeRdQdq0kDTL654LQ/kAzzqLN1LPPQLkTQb
 uYfYrhRI1PS5mvkVUara19LRhASkok6+plOrXOWSBefO9LP24tQulsqpLtv+ZLBL3I
 eZJTyTH1pU0BukA/fbVloyoaVnPwJsLec87zC59hM0bwGdjIDR7gGmr8+gqLpwS7jV
 RsBr6AKSEQ5BUpSYXDzw8bGFyZEERZjhAtDwQds2hL8+YyGwuG+wrt2OPx18/a00UU
 VBRpAj+DS5UKG9Lzu3uv1aNJWmhhC7O5RhipZtYuOsuPIj5f6PFmbaRcOCy00eF0Qa
 S7+FN/TnZHBRQ==
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)


--=-ZvJgKHzxoMfdkoDaCPjm
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Maxime Devos schreef op za 17-04-2021 om 22:07 [+0200]:
> bo0od schreef op za 17-04-2021 om 18:29 [+0000]:
> >=20
> > [...]
> > - Bloating the disk size
>=20
> About 200 GiB or so in my case, though admittedly that's partially becaus=
e
> I never run "guix gc" or that command for deleting old generations

Correction -- it seems I have 129GiB in my home directory. (du --total $HOM=
E)
I thought it was at most 40 GiB or so.  Replace 200GiB with 100GiB.


--=-ZvJgKHzxoMfdkoDaCPjm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYHwDNRccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7uIfAQDvJNPLNJJPy+8WSKthdHm3bnS+
HzINzJ7rNn4zJAuT/AD+MJgRiocKhvXghQ04EL6cghjs+vC7jf3xpgH+dHbZ9w0=
=qGeD
-----END PGP SIGNATURE-----

--=-ZvJgKHzxoMfdkoDaCPjm--





Message sent to bug-guix@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#47846: Feature Request: Add ability to disable having cache or generations
Resent-From: bo0od <bo0od@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sun, 18 Apr 2021 14:41:01 +0000
Resent-Message-ID: <handler.47846.B47846.16187568469299 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 47846
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Leo Prikler <leo.prikler@HIDDEN>, 47846 <at> debbugs.gnu.org
Received: via spool by 47846-submit <at> debbugs.gnu.org id=B47846.16187568469299
          (code B ref 47846); Sun, 18 Apr 2021 14:41:01 +0000
Received: (at 47846) by debbugs.gnu.org; 18 Apr 2021 14:40:46 +0000
Received: from localhost ([127.0.0.1]:47392 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lY8bO-0002Pu-56
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 10:40:46 -0400
Received: from mx1.riseup.net ([198.252.153.129]:44912)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bo0od@HIDDEN>) id 1lY8bM-0002Ph-Rk
 for 47846 <at> debbugs.gnu.org; Sun, 18 Apr 2021 10:40:45 -0400
Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83])
 (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 4FNXgC0xP0zDqq6;
 Sun, 18 Apr 2021 07:40:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1618756839; bh=m0+CfcwtlyGd2cvfRZVsR9mcjeyzaAiiSE79G6sz9QU=;
 h=Subject:To:References:From:Date:In-Reply-To:From;
 b=rrxhumlpWJPnp9+DKvjg7FwdLW/elBPpw5BVMeeSHIKqNqYNKNfmF2uI159RzfLxA
 xlm9FROJsODmXwaWDCIyYCwCAv85ICwhxCAdBg6n2Ws+2XJAccdj3gs25L4ijTFNGn
 g5hMp0+7BpRvGYjQWTGuCUknFuVlDhqnt0UHxZA4=
X-Riseup-User-ID: 46200724123CB94D511B408151A4B482629DA1CAC07758C51AF255AAEAFD5E4D
Received: from [127.0.0.1] (localhost [127.0.0.1])
 by fews1.riseup.net (Postfix) with ESMTPSA id 4FNXg92JJZz5w2G;
 Sun, 18 Apr 2021 07:40:36 -0700 (PDT)
References: <df61f8dd-ca00-a419-a751-46d39b1c9f00@HIDDEN>
 <34dd59bee8f503432a3eea3c55dde95a23ecc7f1.camel@HIDDEN>
From: bo0od <bo0od@HIDDEN>
Message-ID: <9520d229-1188-bf19-f8e6-9747b7a0ed11@HIDDEN>
Date: Sun, 18 Apr 2021 14:40:34 +0000
MIME-Version: 1.0
In-Reply-To: <34dd59bee8f503432a3eea3c55dde95a23ecc7f1.camel@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.8 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.2 (/)

 > There is no active caching going on.

Not sure what do you mean by this.

 > but on a desktop with 500MB storage, you can keep several
months of that around if you want to.

Im using 20GB+9GB swap, its nightmare you cant just upgrade without each 
and everytime delete cache. So no, Sorry The statement isnt accurate 
about 500MB. (my personal experience, not someone telling me nor 
guessing things)

 > Which is bad how?

Imagine i upgraded to FF version 79, but as well i have 78.9.2,78.9.0... 
These are wasted software we are not hunting deer and keeping trophies, 
  Dont get me wrong roll back is great/usable but not for 
everyone/everytime case.

 > You would have to explicitly run those old, insecure versions, for 
them to be an attack surface[...]

True, Already answered by Leo Famulari.

 >Just FYI deleting all that so often only puts unnecessary stress on
your disk, because native inputs will have to be redownloaded and
you're not even freeing up that much space.

There is no way i can upgrade without using them.

 > That's not very functional.  Again, you're putting more stress on your
hardware by actively asking it to remove stuff.

If you mean by the method of removing, Thats not my job to know what is 
the best method to be used, There are main distros like 
debian,fedora..etc devs can look at them and see how they can 
adopt/merge some methods.

Leo Prikler:
> Hi,
> Am Samstag, den 17.04.2021, 18:29 +0000 schrieb bo0od:
>> 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.
>>
>> B) System Packages: Same process but it will be saved through
>> generations
> There is no active caching going on.  Besides potentially building
> software, the process of "upgrading" one generation of your Guix
> profile or system is simply the act of letting a symbolic link point
> elsewhere.  Nothing more, nothing less.  Each generation is itself a
> "root" in GC terms from the moment it is built.
> 
>> This causes unpleasant actions to some users:
>>
>> - Bloating the disk size
> That's debatable.  Now, yes, it is no secret, that Guix uses more disk
> space than your traditional software, as keeps copies of your old data
> around, but on a desktop with 500MB storage, you can keep several
> months of that around if you want to.  Things might be a bit different
> on smartphones and embedded systems, which may want to GC more often,
> but it's not like minimal setups are impossible.
>> - Having old unnecessary files/packages
> Which is bad how?
>> - Questionable security of the saved old versions. 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)
> You would have to explicitly run those old, insecure versions, for them
> to be an attack surface, which I'd hazard you won't unless you're still
> actively using them anyway.  Note that for the case, that the mere
> existence of those is a threat, you must assume your attacker to have
> arbitrary shell code execution already.
> 
>> 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).
> Because it is.  There are things larger than package generations.  My
> current profile weighs 8.5GB according to du, much of which can be
> shared between generations.  A typical anime episode encoded with x264
> at 1080p weighs 1GB or more.  So one season of your favourite show is
> literally more data than all of your software.
> 
>> Current manual solution is to delete this extra mess using 2
>> commands:
>>
>> guix gc -d 1s && sudo guix system delete-generation
>>
>> This should be run whenever there is no space left, Or to get rid of
>> the
>> old stuff
> Just FYI deleting all that so often only puts unnecessary stress on
> your disk, because native inputs will have to be redownloaded and
> you're not even freeing up that much space.
> 
>> My suggestion is to have the ability to make Guix automatically just
>> having the latest up to date packages without extra consumed storage
>> (no
>> cache no generation no nothing more than having the latest packages
>> available in the distro).
> That's not very functional.  Again, you're putting more stress on your
> hardware by actively asking it to remove stuff.
> 
> Regards,
> Leo
> 




Message sent to bug-guix@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#47846: Feature Request: Add ability to disable having cache or generations
Resent-From: Leo Prikler <leo.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sun, 18 Apr 2021 15:40:02 +0000
Resent-Message-ID: <handler.47846.B47846.161876037614955 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 47846
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: bo0od <bo0od@HIDDEN>, 47846 <at> debbugs.gnu.org
Received: via spool by 47846-submit <at> debbugs.gnu.org id=B47846.161876037614955
          (code B ref 47846); Sun, 18 Apr 2021 15:40:02 +0000
Received: (at 47846) by debbugs.gnu.org; 18 Apr 2021 15:39:36 +0000
Received: from localhost ([127.0.0.1]:47493 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lY9WJ-0003t9-IU
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 11:39:35 -0400
Received: from mailrelay.tugraz.at ([129.27.2.202]:5786)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <leo.prikler@HIDDEN>) id 1lY9WH-0003sz-5E
 for 47846 <at> debbugs.gnu.org; Sun, 18 Apr 2021 11:39:34 -0400
Received: from nijino.local (194-96-9-9.adsl.highway.telekom.at [194.96.9.9])
 by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4FNYz52HtVz1LLyL;
 Sun, 18 Apr 2021 17:39:28 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4FNYz52HtVz1LLyL
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at;
 s=mailrelay; t=1618760369;
 bh=xjfecxmOEZTRU86ocyEEpunWKQ5oLoKo67uy9TPmXwE=;
 h=Subject:From:To:Date:In-Reply-To:References:From;
 b=M1x3f4/0IvTweJOGQUXutbT+ArRlrLU/vgB6fLxK74uYhwEh9r1XH+ezab0lE6jVP
 vyznX/jIFg+HS26NV2R+jEt+wXouPge7s4i3hcL48s0t4dWpZV5SpIVUaHPdDeOWTf
 NQovtWAcInV9KMaXBoEb8gxrb4FJMov1AqoMgSxc=
Message-ID: <673a04816e4ea2e12d4dfda2cda43ec64eb0d50d.camel@HIDDEN>
From: Leo Prikler <leo.prikler@HIDDEN>
Date: Sun, 18 Apr 2021 17:39:28 +0200
In-Reply-To: <9520d229-1188-bf19-f8e6-9747b7a0ed11@HIDDEN>
References: <df61f8dd-ca00-a419-a751-46d39b1c9f00@HIDDEN>
 <34dd59bee8f503432a3eea3c55dde95a23ecc7f1.camel@HIDDEN>
 <9520d229-1188-bf19-f8e6-9747b7a0ed11@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.2 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw
X-Spam-Scanner: SpamAssassin 3.003001 
X-Spam-Score-relay: -1.9
X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Hi,

Am Sonntag, den 18.04.2021, 14:40 +0000 schrieb bo0od:
>  > There is no active caching going on.
> 
> Not sure what do you mean by this.
Exactly what I said.  There is a philosophical difference between a
store, that keeps items as long as there's a referrer and a cache,
which keeps some items on a heuristic basis.

>  > but on a desktop with 500MB storage, you can keep several
> months of that around if you want to.
> 
> Im using 20GB+9GB swap, its nightmare you cant just upgrade without
> each 
> and everytime delete cache. So no, Sorry The statement isnt accurate 
> about 500MB. (my personal experience, not someone telling me nor 
> guessing things)
My bad, I meant to type 500GB (a fairly common disk size), but it turns
out my other laptop survives quite fine on 250.  Fair enough, it's not
32GB (common in phones), but then again, you'd run normally very
different packages on embedded systems.

And yeah, this is also personal experience, not someone telling me or
guessing, I merely made a typo.

> 
>  > Which is bad how?
> 
> Imagine i upgraded to FF version 79, but as well i have
> 78.9.2,78.9.0... 
> These are wasted software we are not hunting deer and keeping
> trophies, 
>   Dont get me wrong roll back is great/usable but not for 
> everyone/everytime case.
You do know, that Guix also has environments, that can be garbage
collected, as soon as the process exits, right?  If you use Icecat so
rarely, that upgrading it along with the rest of your profile makes no
sense, you could use those.  Not to mention w.r.t. security, using a
containerized icecat is probably a better idea.

>  >Just FYI deleting all that so often only puts unnecessary stress on
> your disk, because native inputs will have to be redownloaded and
> you're not even freeing up that much space.
> 
> There is no way i can upgrade without using them.
There are several ways of optimizing for profile size, one of which is
to not run huge browsers like icecat.  I have no idea what kind of
system you're trying to fit into 20GB , but a hard idea thinking it's
the right kind.

By the way, continuing from before, my /run/current-system, which
consists of the desktop template plus some extras, seems to weigh just
about 2GB, which would fit 5 times into 20GB while still letting me use
half of the disk.

>  > That's not very functional.  Again, you're putting more stress on
> your
> hardware by actively asking it to remove stuff.
> 
> If you mean by the method of removing, Thats not my job to know what
> is 
> the best method to be used, There are main distros like 
> debian,fedora..etc devs can look at them and see how they can 
> adopt/merge some methods.
What kind of advanced removal strategies are you talking about?
Traditional distros do not face this issue, because they're more or
less just dumping files into already existing locations, and don't
really worry whether something already exists there.  (Well, there are
varying degrees of worrying, but they are all incomplete.)  Binary
distros have it even easier, because they don't even attempt to build
from source (another issue if you're running a resource-constrained
device).

These so-called "removal methods" of traditional distros are
antithetical to Guix' design.  Asking us to behave just like a "main
distro", when we have made a clear decision not to, is not going to
please either side of the discussion.

Regards,
Leo





Message sent to bug-guix@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#47846: Feature Request: Add ability to disable having cache or generations
Resent-From: bo0od <bo0od@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sun, 18 Apr 2021 17:44:02 +0000
Resent-Message-ID: <handler.47846.B47846.161876780419299 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 47846
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Maxime Devos <maximedevos@HIDDEN>, 47846 <at> debbugs.gnu.org
Received: via spool by 47846-submit <at> 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 <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lYBS6-00051C-Oa
	for submit <at> 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 <bo0od@HIDDEN>) id 1lYBS0-00050q-2N
 for 47846 <at> 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: <df61f8dd-ca00-a419-a751-46d39b1c9f00@HIDDEN>
 <726ce75bd7bb4424703c608b0c51a6c8eb6a2662.camel@HIDDEN>
From: bo0od <bo0od@HIDDEN>
Message-ID: <ca2ff898-92e8-9112-cde0-f47095f9898b@HIDDEN>
Date: Sun, 18 Apr 2021 17:43:04 +0000
MIME-Version: 1.0
In-Reply-To: <726ce75bd7bb4424703c608b0c51a6c8eb6a2662.camel@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.8 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.2 (/)

 > 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
> 




Message sent to bug-guix@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#47846: Feature Request: Add ability to disable having cache or generations
Resent-From: bo0od <bo0od@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sun, 18 Apr 2021 18:46:02 +0000
Resent-Message-ID: <handler.47846.B47846.161877152925351 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 47846
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Leo Prikler <leo.prikler@HIDDEN>, 47846 <at> debbugs.gnu.org
Received: via spool by 47846-submit <at> debbugs.gnu.org id=B47846.161877152925351
          (code B ref 47846); Sun, 18 Apr 2021 18:46:02 +0000
Received: (at 47846) by debbugs.gnu.org; 18 Apr 2021 18:45:29 +0000
Received: from localhost ([127.0.0.1]:47775 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lYCQD-0006ap-59
	for submit <at> debbugs.gnu.org; Sun, 18 Apr 2021 14:45:29 -0400
Received: from mx1.riseup.net ([198.252.153.129]:47248)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bo0od@HIDDEN>) id 1lYCQB-0006ab-Tr
 for 47846 <at> debbugs.gnu.org; Sun, 18 Apr 2021 14:45:28 -0400
Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83])
 (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 4FNf5M6SSQzDv4S;
 Sun, 18 Apr 2021 11:45:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1618771522; bh=KhyVytunn2q3TVLI4j2ctx4BLAssn0QeB/lJ6a2W018=;
 h=Subject:To:References:From:Date:In-Reply-To:From;
 b=itkfPSGoLalgbO0jxKRvTAwFiJY1YKXmgRXR/DyjgwXc3KMNt5rJCTVZSvXTHRc7z
 EQHrtdCZJNMGQXT1hrmwO87zf9dA/tzPvHsYAn2Cq2cej3b+13K+7mFQ7wKe8p9zaL
 dsc1KuAV7JRM3nvHOHukrbjs/WirM+0io8LjhsM0=
X-Riseup-User-ID: 1CF75E676A191BAEE0FB21C1FAB15A04C4F5307EEED84C5AB19BFDF367851548
Received: from [127.0.0.1] (localhost [127.0.0.1])
 by fews1.riseup.net (Postfix) with ESMTPSA id 4FNf5L1Y1Jz5w5X;
 Sun, 18 Apr 2021 11:45:09 -0700 (PDT)
References: <df61f8dd-ca00-a419-a751-46d39b1c9f00@HIDDEN>
 <34dd59bee8f503432a3eea3c55dde95a23ecc7f1.camel@HIDDEN>
 <9520d229-1188-bf19-f8e6-9747b7a0ed11@HIDDEN>
 <673a04816e4ea2e12d4dfda2cda43ec64eb0d50d.camel@HIDDEN>
From: bo0od <bo0od@HIDDEN>
Message-ID: <6d08fb6e-8fb6-8990-aa85-423bcc4f9ddd@HIDDEN>
Date: Sun, 18 Apr 2021 18:45:05 +0000
MIME-Version: 1.0
In-Reply-To: <673a04816e4ea2e12d4dfda2cda43ec64eb0d50d.camel@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.8 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.2 (/)

 > My bad, I meant to type 500GB (a fairly common disk size), but it turns
 > out my other laptop survives quite fine on 250.  Fair enough, it's not
 > 32GB (common in phones), but then again, you'd run normally very
 > different packages on embedded systems.

yeah 100+ GB thats too big, not always having this space is easy or 
available.

 > There are several ways of optimizing for profile size, one of which is
 > to not run huge browsers like icecat.  I have no idea what kind of
 > system you're trying to fit into 20GB , but a hard idea thinking it's
 > the right kind.

I have debian,fedora,kali,ubuntu,trisquel/triskel,arch... all with only 
20GB space and working for testing purposes as im mostly working as 
software tester.

 > What kind of advanced removal strategies are you talking about?

I didnt suggested how its done in my ticket, I gave the issue and 
feature request as a solution to it but how to do it the best way i 
leave this to the devs to decide not me.

If out of ideas and nothing is available look at other distributions and 
see how its done and what can be taken from them and merge into guix to 
adopt this feature.

Leo Prikler:
> Hi,
> 
> Am Sonntag, den 18.04.2021, 14:40 +0000 schrieb bo0od:
>>   > There is no active caching going on.
>>
>> Not sure what do you mean by this.
> Exactly what I said.  There is a philosophical difference between a
> store, that keeps items as long as there's a referrer and a cache,
> which keeps some items on a heuristic basis.
> 
>>   > but on a desktop with 500MB storage, you can keep several
>> months of that around if you want to.
>>
>> Im using 20GB+9GB swap, its nightmare you cant just upgrade without
>> each
>> and everytime delete cache. So no, Sorry The statement isnt accurate
>> about 500MB. (my personal experience, not someone telling me nor
>> guessing things)
> My bad, I meant to type 500GB (a fairly common disk size), but it turns
> out my other laptop survives quite fine on 250.  Fair enough, it's not
> 32GB (common in phones), but then again, you'd run normally very
> different packages on embedded systems.
> 
> And yeah, this is also personal experience, not someone telling me or
> guessing, I merely made a typo.
> 
>>
>>   > Which is bad how?
>>
>> Imagine i upgraded to FF version 79, but as well i have
>> 78.9.2,78.9.0...
>> These are wasted software we are not hunting deer and keeping
>> trophies,
>>    Dont get me wrong roll back is great/usable but not for
>> everyone/everytime case.
> You do know, that Guix also has environments, that can be garbage
> collected, as soon as the process exits, right?  If you use Icecat so
> rarely, that upgrading it along with the rest of your profile makes no
> sense, you could use those.  Not to mention w.r.t. security, using a
> containerized icecat is probably a better idea.
> 
>>   >Just FYI deleting all that so often only puts unnecessary stress on
>> your disk, because native inputs will have to be redownloaded and
>> you're not even freeing up that much space.
>>
>> There is no way i can upgrade without using them.
> There are several ways of optimizing for profile size, one of which is
> to not run huge browsers like icecat.  I have no idea what kind of
> system you're trying to fit into 20GB , but a hard idea thinking it's
> the right kind.
> 
> By the way, continuing from before, my /run/current-system, which
> consists of the desktop template plus some extras, seems to weigh just
> about 2GB, which would fit 5 times into 20GB while still letting me use
> half of the disk.
> 
>>   > That's not very functional.  Again, you're putting more stress on
>> your
>> hardware by actively asking it to remove stuff.
>>
>> If you mean by the method of removing, Thats not my job to know what
>> is
>> the best method to be used, There are main distros like
>> debian,fedora..etc devs can look at them and see how they can
>> adopt/merge some methods.
> What kind of advanced removal strategies are you talking about?
> Traditional distros do not face this issue, because they're more or
> less just dumping files into already existing locations, and don't
> really worry whether something already exists there.  (Well, there are
> varying degrees of worrying, but they are all incomplete.)  Binary
> distros have it even easier, because they don't even attempt to build
> from source (another issue if you're running a resource-constrained
> device).
> 
> These so-called "removal methods" of traditional distros are
> antithetical to Guix' design.  Asking us to behave just like a "main
> distro", when we have made a clear decision not to, is not going to
> please either side of the discussion.
> 
> Regards,
> Leo
> 





Last modified: Sun, 18 Apr 2021 19:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.