This is what I do, from a non-CLI, non-techy perspective.
I usually check through the terminal output after every update, which I do only in terminal. If there are pacnew files but they seem the sort that don’t need immediate changes (you’ll get a feel for it after a while), I just copy that section of the text into a to-do list that I revisit at the next update.
WHen I need to compare the diffs between the existing file and the pacnew file, I use Meld because I like a more visual presentation of the changes.
Here are some basic things I’ve picked up through using Manjaro for quite a few years:
-
don’t mess with pacnew files for shadow, gpassword and the like.
-
often a vanilla config file is being provided by way of a pacnew file because a program developer has just updated their program. Your version of the config file on your system will of course have the configurations you made, and adopting the dev’s changes wholesale won’t be good for you since it wipes your changes away. Examples: glibc deals with your locale and language, and the pacnew file will have ALL locales and languages – including yours – commented out, which is of course not what you want. Another example: if you have an update to lightdm, there may be a pacnew for the lightdm-greeter file. This one you’ll need to check carefully, because if like me you’ve used the GUI Lightdm Greeter config tool to tweak the appearance, change background, etc, then fully replacing your config file with the vanilla greeter config file will wipe out all your changes. Even for pamac, you might have enabled access to AUR and its updates. When there is a pamac pacnew file, that AUR setting is disabled again since that is the default setup for pamac.
-
pretty often, the pacnew file will present new functionality in the program that it configures. Since it’s new, the new stuff is likely to be all commented out, since you haven’t used or enabled the new functionality. For these, since they are all commented out anyway, I just merge them into my original config file, especially if it’s a simple one-for-one replacement of a completely commented-out section in the original.
-
Similarly, if you generally keep to the default settings in most programs, some of the original settings in your own config file may be commented out since you never touched it. So long as the pacnew file has these settings commented out as well, that’s fine. If it looks like it’s changed or been enabled, I may copy over (not merge) the new section but comment it out (ie, disabled) and also add my own comments about this change. If my system still works fine afterwards, great. If I later find out it’s a needed change to the config, at least I know what to change and can find it quickly.
After a while you get a feel for what pacnew changes are needed and what can be ignored.
How do I do the merging if I don’t want to use CLI commands/tools?
-
in Meld, I compare the old and the pacnew file side by side. The changes are marked out visually in blue and green. Meld is not opened as root but as user.
-
I use the Meld tools to adopt certain changes wholesale in the original config file while ignoring others completely. For the rest, you might have to consider the changes more carefully and then just manually type or copy and paste only selected portions to the original file. I leave myself comments and annotations where I’m not sure.
-
when I’m satisfied with the edited original config file in Meld, I open Thunar as root and then open the said original config file in root with an editor. I copy the whole text from the Meld window and replace the contents of the original config file in the root editor. Save and close.