[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
- [bug#56618] [PATCH 1/2] home: Add 'home-generation-base'., (continued)
bug#56618: [PATCH 0/2] Let 'guix gc -d' delete old Home generations, Ludovic Courtès, 2022/07/22