From: Simon Tournier <zimon.toutoune@gmail.com>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: "Ludovic Courtès" <ludo@gnu.org>,
"Ricardo Wurmus" <rekado@elephly.net>,
guix-devel <guix-devel@gnu.org>
Subject: Re: Building and caching old Guix derivations for a faster time machine
Date: Fri, 12 Jan 2024 10:56:29 +0100 [thread overview]
Message-ID: <87jzoeyiwi.fsf@gmail.com> (raw)
In-Reply-To: <87zfyv4bgc.fsf@gmail.com>
Hi Maxim,
On Thu, 30 Nov 2023 at 08:28, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
> I'd like to have a single archive type as well in the future, but I'd
> settle on Zstd, not lzip, because it's faster to compress and
> decompress, and its compression ratio is not that different when using
> its highest level (19).
When running an inferior (past revision), some past Guile code as it was
in this past revision is launched. Hum, I have never checked: the
substitution mechanism depends on present revision code (Guile and
daemon) or on past revision?
Other said, what are the requirements for the backward compatibility?
Being able to run past Guix from a recent Guix, somehow.
>> 1. Keep for as longer as we can all the requirements for running Guix
>> itself, e.g., “guix time-machine”. Keep all the dependencies and all
>> the outputs of derivations. At least, for all the ones the build farms
>> are already building.
>>
>> 2. Keep for 3-5 years all the outputs for specific Guix revision, as
>> v1.0, v1.1, v1.2, v1.3, v1.4. And some few others.
>
> That'd be nice, but not presently doable as we can't fine tune retention
> for a particular 'derivation' and its inputs in the Cuirass
> configuration, unless I've missed it.
That’s an implementation detail, a bug or a feature request, pick the
one you prefer. ;-)
We could imagine various paths for these next steps, IMHO. For
instance, we could move these outputs to some specific stores
independent of the current ones (ci.guix and bordeaux.guix). For
instance, we could have “cold” storage with some cooking bakery for
making hot again, instead of keeping all hot. For instance, we could
imagine etc. :-)
Well, I do not have think much and I just speak loud: Cuirass (and Build
Coordinator) are the builders, and I would not rely on them for some NAR
“archiving“, instead maybe “we” could put some love into the tool
nar-herder. Somehow, extract specific NAR that the project would like
to keep longer than the unpredictable current mechanism.
Cheers,
simon
next prev parent reply other threads:[~2024-01-12 12:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-10 9:29 Building and caching old Guix derivations for a faster time machine Ricardo Wurmus
2023-11-16 9:59 ` Simon Tournier
2023-11-16 15:39 ` Ludovic Courtès
2023-11-18 4:27 ` Maxim Cournoyer
2023-11-22 18:27 ` Ludovic Courtès
2023-11-29 16:34 ` Simon Tournier
2023-11-30 13:28 ` Maxim Cournoyer
2023-11-30 14:05 ` Guillaume Le Vaillant
2023-12-05 1:18 ` Maxim Cournoyer
2024-01-12 9:56 ` Simon Tournier [this message]
2024-01-15 4:02 ` Maxim Cournoyer
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=87jzoeyiwi.fsf@gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
--cc=maxim.cournoyer@gmail.com \
--cc=rekado@elephly.net \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
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).