bug#47846: Feature Request: Add ability to disable having cache or generations

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1: Type: text/plain, Size: 5945 bytes --]

bo0od schreef op za 17-04-2021 om 18:29 [+0000]:
> Hi There,
> 
> Current situation with the guix distro upgrade is:(as i understand)
> 
> A) User Packages: whenever there is an upgrade to package A version 1 to 
> new Version lets call it A version 2 , So the process is ADD A2 → SWITCH 
> to A2 → Cache A1 and so on.

There isn't really any caching, it's more like garbage collection like in
Guile, other Schemes & lisps, Java, ..., where old objects (package versions
& profiles that aren't referred anywhere anymore) are deleted.

Is that informative for you?

When the user upgrades A from version A1 to version A2, creating a new version
of the profile P2:

  * P1: original profile, referring to the binaries of A1
    (and other packages, which I'll ignore here)
  * The user asks guix to upgrade from A1 to A2.  So guix first builds A2.
  * Guix creates a profile P2, referring to the binaries of A2
  * P2 becomes the current profile.
  * P1 is kept around in case the user isn't satisfied, or is feeling nastolgic
    or something

> B) System Packages: Same process but it will be saved through generations

In case of user packages, old generations are also saved.
Try "guix package --list-generations".  I have 128 generations of bloat.
Lemme update ("guix package -u"), soon I'll have 129 generations of bloat.

So the bloat is even worse, and your point is even more compelling!

> This causes unpleasant actions to some users:
> 
> - Bloating the disk size

About 200 GiB or so in my case, though admittedly that's partially because
I never run "guix gc" or that command for deleting old generations

> - Having old unnecessary files/packages

Well, having ... They are just sitting there under /gnu/store. A user won't
accidentally see them or something.  Aside from
taking in disk space (see ‘Bloating the disk size’), this seems harmless.

> - Questionable security of the saved old versions.

As long as you don't run the old versions, you should be fine.
If you actually run the old versions, then you'll get the old packages
with old security bugs.  If they can connect to the network, best disconnect
first.

Only run old (and therefore possibly with publicly-known and unfixed security
issues) issues on trusted data!  Use case I have in mind:

  /.../old-profile-version/bin/tome4  (when you've disabled Internet access,
    for trying an old version of tome4 (a game) to see what has changes since).

>  As it depend if they 
> have access to suid or not (i didnt investigate this, but if they have 
> then thats big problem but this is not the ticket to discuss it)

"guix package -i" never creates setuid/setgid binaries.  The only setuid/setgid
binaries that guix creates are in /run/setuid-programs.  These are setuid/setgid
_copies_ of what's requested in the _current_ (or the one at boot, I forgot)
operating-system declaration.

> I know someone would jump in and say but roll back is great feature and 
> its useful and....i know that but like i said might be not suiting all 
> users (specially with limited space).

Yes, but let's at least keep the last few generations around.

E.g., I actually _almost_ never use the rollback mechanism.  The only
time was when I messed up the operating-system declaration, so I had to boot
into the previous system generation (is that the term?).

Of course, then there's a choice to make for _how many_ generations to keep
around ...

> Current manual solution is to delete this extra mess using 2 commands:
> 
> guix gc -d 1s && sudo guix system delete-generation

You should run them in the opposite order.
Also, "guix package --delete-generations" should be run for each user.

> This should be run whenever there is no space left,

Tricky ... reportedly, many software does not handle out-of-disk-space errors
well.  Also, letting "guix gc" and "guix package --delete-generations" run
takes some time.  So this would have to be run when there's only 10% disk
space left or something like that.

> Or to get rid of the old stuff

When you've the space, I recommend keeping the ‘old stuff’ around.
You'd never know whether you'll need it later!  In case you'll need it later,
keeping the ‘old stuff’ around saves on Internet traffic (saving some time)
(lessening the load on the substitute servers -> less network and disk I/O and
CPU usage --> less monetary costs, less environmental cost).

> My suggestion is to have the ability to make Guix automatically just 
> having the latest up to date packages

There's an unattended-upgrade-service for the system profile (if that's the
result of operating-system).  Maybe we can have something similar for user
profiles.

> without extra consumed storage (no cache no generation no nothing more than
> having the latest packages available in the distro).
> 
> So the process is ADD A2 → SWITCH to A2 → Delete A1 , Or Download A2 → 
> Replace over A1 and so on.

This in-place replacement you seem to be suggesting, is rather counter one of
the primary goals of Guix (and Nix, for that matter) --- functional package
management.

Automatically deleting the previous profile and trying to delete the previous
version whenever possible could be possible, but I'm not sure it's worth it.

You could try to implement it yourself, and try your modified guix out for
a while, and report whether it seems to work well, of course!

However, I believe the following would be easier in the short term
(and *very* likely to be accepted upstream):

Implement a graphical application (maybe using the guile-gnome bindings,
or as a web app run on localhost) that has a few buttons for collecting
garbage and deleting old profiles.  Guix could use some graphical stuff.

Of course, what you decide to hack on, what approaches you'll take, etc.
is up to you!

Greetings,
Maxime

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]