Discussion about handling orphaned packages

[Javabean]

@BluishHumility

I think this illustrates @ShalokShalom’s point, that oftentimes it is difficult or impossible to determine the significance of the orphans being removed.

that was indeed the point of my exercise. i simply wanted to show what happens when you try to do that from a stock(but upgraded) install.

[anon71037787]

@BluishHumility

The notion that we need to make the option of blindly removing packages safe somehow is ridiculous.

No. It’s a basic function of an operating system. If not even removing packages can be safe, that’s a pretty low standard.

I don’t think we, as a distro, have much to say about this, other than what Garuda already does.
And I am completely fine with that.

[anon71037787]

@BluishHumility

You can automate cleaning the cache more aggressively if you want with paccache.timer:

https://wiki.archlinux.org/title/pacman#Cleaning_the_package_cache

Yeah, I know that. I was arguing to change that default. As in, this is, actually, severely limiting the user’s experience, as so much of the hard space is lost.

And most users probably don’t even know, they could clean it.

I would set this down to one level of stored package generations.

[BluishHumility]

@anon71037787

Yeah, I know that. I was arguing to change that default.

I prefer to more aggressively prune these files as well. I rarely need the package cache. Even when I am downgrading a package, it’s usually something that is available in the Arch Linux Archive anyway.

Plus, with Btrfs snapshotting there are even more options for rolling back packages.

Still, just to play devil’s advocate, here are a few considerations why this might not be a desirable default configuration:

• Some users prefer to keep more versions. When it comes to deleting user data, the more conservative option is to allow users to decide for themselves what should be kept or removed.
• Garuda uses two repositories ([garuda] and [chaotic-aur]) which are not backed up by the Arch Linux Archive. If the package cache is deleted, downgrading these packages is not possible. The user would need to restore a Btrfs snapshot to roll back one of these packages.
• Garuda Assistant already includes a built-in tool for cleaning the package cache. If users want to free up some space all they need to do is click the button and put in their password. Honestly this one tool seems like it should be enough for most users.

Instead of setting a default that most users may have difficulty figuring out how to interact with, another idea would be to try to make the current tools more accessible. I think EOS does a pretty good job with this, check out their GUI tool for configuring package cache maintenance:

Ultimately though, I think users who care about this can set it up for themselves because it is not hard.

@anon71037787

I would set this down to one level of stored package generations.

An easy way to do this would be to set a Pacman hook.

sudo micro /etc/pacman.d/hooks/paccache.hook

[Trigger]
Operation = Remove
Operation = Install
Operation = Upgrade
Type = Package
Target = *

[Action]
Description = Keep the last cache and the currently installed.
When = PostTransaction
Exec = /usr/bin/paccache -rvk2

This will clear all packages from the cache except the currently installed and the one previous after every Pacman transaction. (source)

[anon71037787]

@BluishHumility

Instead of setting a default that most users may have difficulty figuring out how to interact with, another idea would be to try to make the current tools more accessible.

I would just pop a notification, in case the cache exceeds a certain limit.

In that case, the user gets aware about the functionality, and can’t run into dozens of Gigabytes being occupied without knowing why and where.

Similarly, as we notify about partial updates already.

@BluishHumility

An easy way to do this would be to set a Pacman hook.

Is this not what this setting is for?

It doesn’t work in my case, but I thought its a bug (that I already reported)