You are not logged in.
The command "paccache -r" keeps by default the last 3 versions, which feels like a recommendation. But what about keeping only the 2 last? Would that be fine?
I need to make space in my system partition, as it keeps complaining each time i update, despite cleaning the cache each time with the aforementioned command.
Last edited by charlie (2019-04-10 19:19:45)
Offline
How big is the partition that /var/cache/pacman resides on?
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
The last one until you figured the updated system boots and gets network access. Then I for one purge the cache.
Offline
Concerning the connection, I'd rather err on the safe side and keep the opportunity to downgrade without access to internet.
The partition is 60Gb, should be quite enough theoretically.
I have just cleared down to 2 versions rather than 3 (with "paccache -rk 2"), now the cache is 13Gb. I have also removed a useless package amounting for roughly 3Gb (! - that package was anaconda).
/usr/share is 6Gb, the only large chunk is TeX related
/opt/cuda 4Gb,
/usr/lib 18Gb, including 3.7Gb for python 3.7 (including tensorflow and torch related stuff of about 2.4Gb)
There's also a /usr/lib/python3.6 which doesn't seem to belong to any package, not sure if I can remove this safely, or just even try to rename it and see what happens... That was probably an attempt to install tensorflow when it was not compatible with Python3.7.
Total 45Gb used.
Last edited by charlie (2019-04-10 19:47:29)
Offline
generally as many as you need. if you log in, and everything works, you don't need an old package.
wine is really the only package that I ever need old versions of because it's prone to introducing errors.
Offline
I keep a backup of the last two on a central server, and clear the cache on all of my machines. In the event I need to rollback on one or more machines, I just copy the package across.
Offline
The problem with keeping a specific number of versions (rather than versions from within a given time period) is that you may not actually be able to download the problematic package if it's dependencies update quickly and are on the 3rd version past what the previous version of the problematic package could use.
Perhaps I should write a script to delete cache packages based on a builddate of a certain age ... here's a start, to delete cached packages older than 30 days old, though for now it only lists candidates rather than removing them:
#!/bin/sh
oldest=$(($(date +%s) - 60 * 60 * 24 * 30))
for pkg in /var/cache/pacman/pkg/*.pkg.tar.xz; do
[ "$(tar xfO $pkg .PKGINFO | sed -n 's/builddate = //p')" -lt "$oldest" ] && echo $pkg
doneLast edited by Trilby (2019-04-10 21:27:48)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
While I do think your @Trilby solution is relatively okay, but what about the packages that don't get updates in a long while?
I mean things like tcpdump or acpi, they are also removed then.
Offline
Why would you need old versions of a package that hasn't been updated?
Offline
You may be right, but still they are installed and don't fall in the category 'dependency problematic'
Offline
Technically, you don't need any if you have a stable connection, use ALA to get whatever you need.
The 'don't need any' part here actually applies even to the current version of packages. Once you've verified that things are working, the cached current packages are... unlikely to be ever used (re-installing isn't really a fix for almost anything). Hence why we have -Scc
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
Rethinking my build-date approach, it would need some revision to be of much use. It seems reasonable to me to keep 1 older version of any package that has been updated recently (e.g., 30 days in my first attempt) as that time period gives ample time for any issues to surface. But the problem with the approach implemented by my first-draft script is that it will remove the needed previous-version of any package that is updated less-often than monthly. For example, if a rarely updated package gets an upgrade, then one runs my script, then finds a problem with the new version - even if this all happens in the same day, the needed package for a rollback will be gone.
So the right logic (for my intended goal) would be to keep everything built within the last N days and at least one older version of each package that has been rebuilt within the last N days. I may or may not care to get around to making that script, as I'm fine with the potential limitation of `pacchache -rk2`.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Nice one @Trilby, I may just put a version of that in front of my system backup, which is synced weekly to the nas.
Pacman -Sc on steroids, I tested it on my upboard, takes a while but it works..
Offline
In hindsight, under most conditions a find command with -mtime and -delete flags would have the same result, but be much much faster. "Most conditions" here would include a system on which updates are conducted relatively regularly such that the mtime of any cached package is not drastically different from it's build time (e.g., it was not sitting on the mirrors for an extended period of time before making it to your system).
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline