hello
i was going through the Manjaro maintenance wiki and it talks about cleaning ~/.cache
do you yourself do it and has it caused you issues?
also there’s no mention there unlike in the arch wiki about cleaning other Old configuration files;
here’s what written in there:
Old configuration files may conflict with newer software versions, or corrupt over time. Remove unneeded configurations periodically, particularly in your home folder and ~/.config
(also ~/.local/share/).
so same question as above and do you mess with these files and how do you handle them,
or should i not try to fix an unbroken system?
IMO…I’m sure that there are plenty of folks who will vehemently disagree with me.
What for (especially if you don’t have space constraints)? If you’re talking about browser/email caches, empty them from the application provided tools.
I don’t bother. It helps speed things up; and, it gets rebuilt anyway…why start afresh?
You would know when that happens.
You should know when this happens as well. If you remove package $foo, the removal does not touch $HOME. THAT’S when you need to look for old/unneeded configs.
Your whole post is the quintessential solution in search of a problem, based on
you could use bleachbit but use with caution some settings can really screw things up and you have to read what you’re choosing first though. that’s if you want to clean old files and junk. i use it all the time 9 years ago when i use to use ubuntu or debian I’d use it all the time it’s a useful tool
Manjaro is my first rolling release distro that I’m using on my primary machine. In the past, I’ve used fixed releases. I’ve been wondering how it’ll work with XFCE and all the XML config files over time. I think system files will be handled via pacman & pacnew files. But how do you know when something is obsolute/deprecated/unsupported in user config files.
For example, if I run xfconf-query -c xfce4-keyboard-shortcuts -lv, there is a line that says “/providers <<UNSUPPORTED”. I had wondered if there were DTD files to validate the XML config files, so a user could run xmllint on them. Manjaro maintainers must deal with this issue to keep their /etc/skel/.config files up to date. I wonder how they do it.
Here are a few thoughts.
Home Cache
In general I leave cache alone. Good applications (destroy/rebuild) should manage their cache. But it wouldn’t hurt to check cache once in awhile to see if some app has gone wild, no longer installed, or just periodically delete it.
# file size larger than 1G
find ~ -type f -size +1G -printf '%-12s %CY%Cm%Cd %P\n' | sort -nr
# change time greater than 360 days
find ~ -type f -iname '*cache*' -ctime +360 -printf '%CY%Cm%Cd %-12s %P\n' | sort -nr
# find all occurrence of an application (replace NAME)
find ~ -iname '*NAME*'
# if system related I use locate
sudo updatedb # there's a timer for this too
locate --ignore-case --regex NAME
# if just installed, adjust time as needed
find -newermt '1 minute ago'
Journal and Logs
systemctl list-timers
Packages and Updates
Watch the Stable Updates category here or via RSS. The thread is not only an announcement but where user’s are posting problems/fixes related to the upgrade. I think @philm would say if some action was needed (i.e., delete cache). The thread gets loooonnng.
Don’t be too quick to install, but don’t wait too long either
Run pacman-mirrors --status before upgrading
Run DIFFPROG=meld pacdiff after every upgrade
Regarding package cache, see systemctl list-timers
I’ve chosen to run paccache -rk3 -ruk0
Regarding Orphans, for the short time I’ve been on Manjaro I have run pacman -Rns $(pacman -Qdtq). Mainly because I’ve been installing and unstalling to find replacements for kde apps.
When updating (I always use terminal, but all the GUIs AFAIK don’t hide), watch for the lines that spits .pacnew. This happens when you modify the old configuration file from the original that comes with the package, the new file from the new package will then be renamed with .pacnew extension added. After the update, diff the old and new one and see if either you can import necessary bits from the new to the old one then delete the .pacnew or the other way around (but this time, overwrite the old by mv-ing the .pacnew to it). Sometimes, an app may decide to totally change the configuration file format right away with no grace period. In this case, just mv the .pacnew to the old one right away.
There’s a chance it could break when the scenario in the last sentence above happens. And depending on how deep it is in the system, you may lose the easy access (i.e. GUI login and else) and must do recovery from pure CLI environment.
