Eduardo Mercovich <[email protected]> writes: > For English speakers, I didn't understood that before gc I must forget > the roots. That is why the space wasn't liberated.
I can't pretend to understand fully - but new user eyes on a piece of software is always something to pay attention to - and I may guess wrong what the mis-conception was here, but I found the mis-conception I'm thinking of interesting, so bear with me. It seems there could be a mode (perhaps by default) where 'guix upgrade' would do 1) upgrade to a new generation, and then 2) delete the previous generation. I now hear every old-time Guix people scream "oh no, one of the strengths of guix is to have automatical atomic roll-backs", but if you think about the terminology used here, an imperative "upgrade" is not what is happening. "guix upgrade" creates and switches to a new generation, but leaves the old one around. I don't expect my idea to actually be implemented, but maybe it humours someone to think about this from a new user perspective. A compromise would be a 'guix upgrade --preserve-generations=5' which could even be the default (and market it is a improvement to reduce the default ecological footprint of guix), then generations older than 5 are automatically prunted upon an upgrade. Imperative people can use 'guix upgrade --preserve-generations=1' and functional folks can use 'guix upgrade --preserve-generations=INF'. (This thread prompted me to drop 70 old package generations and 25 home generations on my laptop, reducing my storage footprint by ~150GB...) /Simon
signature.asc
Description: PGP signature
