[Top][All Lists]

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

Re: wishlist: “repack” generations history of profile

From: zimoun
Subject: Re: wishlist: “repack” generations history of profile
Date: Mon, 30 May 2022 19:18:49 +0200


On lun., 30 mai 2022 at 17:40, Ludovic Courtès <> 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

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)


reply via email to

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