From: zimoun <zimon.toutoune@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: wishlist: “repack” generations history of profile
Date: Mon, 30 May 2022 19:18:49 +0200 [thread overview]
Message-ID: <87k0a3aqh2.fsf@gmail.com> (raw)
In-Reply-To: <875yln2flm.fsf@gnu.org>
Hi,
On lun., 30 mai 2022 at 17:40, Ludovic Courtès <ludo@gnu.org> wrote:
> Yes, that ‘manifest’ file would have copied elsewhere (we can’t just
> remove part of what’s in a /gnu/store directory).
[...]
>> Instead of this external tracking, I would like to allow this workflow:
>>
>> guix package -p project --list-generations
>> guix package -p project --switch-generation=12
>>
>> whatever the sysadmin collect about the old generations.
>
> Do you expect ‘--list-generations’ to look at older revisions of your
> version-controlled ‘manifest.scm’?
I do not expect that Guix uses my version-controlled ’manifest.scm’ but
instead that Guix uses its own internal one.
If the sysadmin of my cluster does as root “guix gc
--delete-generations=3m”, then this GC is out of my control and
unexpected by me, which somehow breaks the rootless argument.
Other said, because “guix gc” can be run periodically (for good
reasons!), as a user, it is hard to predict what I could loose.
Well, consider the situation:
1. User install foo bar the profile my-project on January
2. User update foo bar on February
3. User works on another project
4. Months later, user works again on my-project
The generation #1 can be lost. For sure it depends on the cluster
policy but, as a sysadmin, I do not tell all the users that a GC will be
run – and even if I am doing, I am sure that some user will miss to save
the channels.scm and manifest.scm for each generation.
That’s why, something like “repack” is missing. As a user, I should be
able to do
guix package --switch-generation=1
whatever the sysadmin collects about the old generations and whatever I
saved using some external tools.
At GC time, enough information of the old generations should be kept
allowing “guix package --switch-generation” or --export-manifest or
else.
We could imagine an intermediary mode between the two current ones:
+ full generation
+ repack (only keep some text files)
+ purge (remove these few text file)
Cheers,
simon
next prev parent reply other threads:[~2022-05-30 18:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-20 13:47 wishlist: “repack” generations history of profile zimoun
2022-05-21 11:30 ` Liliana Marie Prikler
2022-05-23 16:20 ` zimoun
2022-05-23 15:42 ` Ludovic Courtès
2022-05-23 16:58 ` zimoun
2022-05-30 15:40 ` Ludovic Courtès
2022-05-30 17:18 ` zimoun [this message]
2022-06-04 7:39 ` Giovanni Biscuolo
2022-06-05 9:45 ` zimoun
2022-06-05 11:16 ` Giovanni Biscuolo
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k0a3aqh2.fsf@gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.