Re: wishlist: “repack” generations history of profile

[Giovanni Biscuolo]

Hi Simon,

I know you know very well all I'm saying here, I'm just commenting for
casual readers of this thread

zimoun <zimon.toutoune@gmail.com> writes:

[...]

> 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.

I don't know how easy or not is the implementation of this feature and
for sure it would be a plus, but IMHO all users must understand that for
their projects (profiles) to be reproducible and versioned the /only/
way is to keep channels.scm and manifests.scm in a VCS (i.e. git)

> 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.

...except you wish to reproduce the project on another machine, or
/gnu/store is lost or corrupted for some reason

Also consider that sometimes pepole in teams choose to work on the same
project in different (not shared) profiles (i.e. for reproducibility
testing), this way generation history is not the same and the only way
to "sync" would be to exchange channels.scm and manifest.scm

Also, from a collaborative workflow point of view, keeping the two
"reproduce me" files (channels and manifest) is more efficient since
people can describe what (and why) they chenged things between "saved"
project generations; not committed channels.scm and manifests.scm should
be considered "local testing"

IMVHO there is no easy workaround to keeping channels.scm and
manifests.scm in a VCS, better sooner than later users should do it

[...]

Happy hacking! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

signature.asc
Description: PGP signature