guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#56618] [PATCH 0/2] Let 'guix gc -d' delete old Home generations


From: Maxim Cournoyer
Subject: [bug#56618] [PATCH 0/2] Let 'guix gc -d' delete old Home generations
Date: Sun, 24 Jul 2022 22:04:07 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux)

Hi Ludo,

Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>>> It’s an expected annoyance: to determine whether a graft needs to be
>>> applied, we first need to download/build the ungrafted variant, which is
>>> why you’re seeing this (this is worsened by the fact that many packages
>>> are candidates for grafting currently on ‘master’).
>>
>> A perhaps naive idea: could we register GC roots for the ungrafted
>> variant when grafted?  To avoid having to fetch it anew following 'guix
>> gc' ?
>
> And then we need code to remove those GC roots at some point, etc.  To
> me that seems like a can of worms and lack of separation of concerns.

OK.

> A related topic is GC.  If personally only ever use ‘guix gc -F25G’ or
> similar; I almost never run ‘guix gc’ without arguments.  Perhaps we
> should more clearly advocate that and/or have a Guix System service
> enabled by default that does something along these lines.

If I'm not mistaken, the problem with 'guix gc -F' (or guix gc) in
general, is that it doesn't start by deleting the *oldest*, i.e. the
store items the user no longer use/cares about.  So you could have 'guix
gc -F25G' prune these recently fetched non-grafted variants again and
again, if you are unlucky.

Perhaps we could arrange for 'guix gc' to start deleting oldest items
first (as a default behavior)?  Then the above advice would provide more
value.

Thanks,

Maxim





reply via email to

[Prev in Thread] Current Thread [Next in Thread]