unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Mark H Weaver <mhw@netris.org>
Cc: help-guix <help-guix@gnu.org>
Subject: Re: GC hints
Date: Tue, 08 Jan 2019 23:27:46 +0100	[thread overview]
Message-ID: <87r2dmu6n1.fsf@gnu.org> (raw)
In-Reply-To: <87h8f4i69i.fsf@netris.org> (Mark H. Weaver's message of "Sun, 23 Dec 2018 10:58:38 -0500")

Hi,

Mark H Weaver <mhw@netris.org> skribis:

> Chris Marusich <cmmarusich@gmail.com> writes:
>
>> Mark H Weaver <mhw@netris.org> writes:
>>
>>> Hi Ludovic,
>>>
>>> Ludovic Courtès <ludo@gnu.org> writes:
>>>
>>>> Actually, I was also wondering whether we should provide a configurable
>>>> mechanism that would, by default, automatically delete old GC roots and
>>>> maybe even run the GC automatically when needed—similar to what Git
>>>> does.
>>>>
>>>> Thoughts?
>>>
>>> I think it's reasonable to automatically run GC by default, but I would
>>> strongly advise against deleting GC roots automatically by default
>>> without the user's knowledge and consent.
>>
>> Just to be clear, I agree with you, Mark.  Guix shouldn't delete GC
>> roots automatically by default.  I think we were just saying that it
>> might be nice if a user could configure Guix to automatically delete GC
>> roots according to some policy (e.g., retain the last 2, and delete any
>> others older than 1 month).  Guix would only delete the GC roots
>> according to the policy that the user has set, and if no policy has been
>> set, the default would be not to delete any of the GC roots.
>
> As long as it's not the default behavior, I think this would be a nice
> feature to have.

Yes, that would sound like a reasonable default to me.

Thinking more about it, we could imagine the equivalent of Git packs:
for old generations, we’d remove the GC root itself, but we’d store
metadata that would allow us to rebuild the thing.

That’s not always possible in general, but in some cases it is: for
‘guix pull’ profiles, we’d just need to store the channel commits and
URLs, and that’s all it’d take to rebuild them.  We could arrange for
‘guix pull -l’ to traverse these seamlessly.

For ~/.guix-profile we could perhaps keep a GC root to the profile’s
derivation but not the profile itself.  That way you could still rebuild
things afterwards.

Anyway, that’s very much science fiction at this point.

Ludo’.

      parent reply	other threads:[~2019-01-08 22:27 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-08 10:53 About /var/guix/profiles and guix pull generations Pierre Neidhardt
2018-12-09  4:35 ` Chris Marusich
2018-12-09 12:40   ` Pierre Neidhardt
2018-12-09 12:40     ` Pierre Neidhardt
2018-12-09 13:38       ` Pierre Neidhardt
2018-12-09 22:21         ` Chris Marusich
2018-12-10  8:22           ` Pierre Neidhardt
2018-12-17  9:12             ` Pierre Neidhardt
2018-12-19  2:48             ` Chris Marusich
2018-12-19  7:49               ` Pierre Neidhardt
2018-12-19 16:16                 ` Chris Marusich
2018-12-19 16:28                   ` Pierre Neidhardt
2018-12-19 16:31                     ` Pierre Neidhardt
2018-12-19 16:49                       ` Pierre Neidhardt
2018-12-25 17:51                         ` swedebugia
2018-12-25 18:49                           ` Pierre Neidhardt
2018-12-26  0:09                             ` swedebugia
2020-05-20  8:26                         ` Pierre Neidhardt
2018-12-19 13:49         ` GC hints Ludovic Courtès
2018-12-19 14:31           ` Pierre Neidhardt
2018-12-19 14:49           ` Ricardo Wurmus
2018-12-19 16:25           ` Chris Marusich
2018-12-20 12:12           ` Mark H Weaver
2018-12-20 20:03             ` Alex Kost
2018-12-21  8:30             ` Chris Marusich
2018-12-21  8:47               ` swedebugia
2018-12-23 15:58               ` Mark H Weaver
2018-12-25 12:05                 ` swedebugia
2018-12-25 14:00                   ` Pierre Neidhardt
2019-01-08 22:27                 ` Ludovic Courtès [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r2dmu6n1.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=help-guix@gnu.org \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).