it must be understood that it’s impossible to provide a general tutorial for all pacnews!
Each pacnew (configuration file) is written by the application developer and therefore each file is different and may require a very different action.
for me: it’s a great opportunity to read wiki/man and learn things, and sometimes also an opportunity to configure better my system.
EDIT: yes meld is a good gui for help
But, using pacdiff in my owns space (no sudo) will not overwrite any systemfiles, I assume (hope)
nope… you could try the other options … but they wont be effective (besides s - ‘skip’).
I provided no sudo just in case.
But you could use any of those diff programs with pacdiff and sudo … and dynamically merge/edit them.
Yes, it is educational, and yet again more stuff for in that little book of mine, but this one is super scary…
Super, so I’mm dive into getting used to this…
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.
Thanks so much. I have highlighted your post, and saved it as a document (plain text, so I can read it in CLI, in case I break the GUI)…
Melissa
@Yochanan posted this bash script on the old forum which has worked well for me
it scans for .pacnew files and opens them in meld to edit
when meld is closed terminal asks user permission to delete the .pacnew
I am using pacui + yay and diffprog is set to “nvim -d” and never had much troubles merging them.
I am prompted for pacnew only if theres a new entries to that files.
I only merge stuff I understand what they do.
Example,
I uncommented an option somwere to enable advance feature and pacnew file will show it as a change. I know I did that uncommenting so I leave it there.
When it’s a change of syntax or a rewrite of some comments I do merge, because that psychologically helps during the next pacnew merge where there is less to merge.
When a number in a shadow file has changed I strictly avoid merging those because for the love of can’t understand why the packages brings with them that file that if merged gives user a huge troubles.
EDIT: eh, it just happened to another soul Chose "overwrite" old files with .pacnew - now can't login
Super! I never did edit any configs, so I assume I’ll be in the clear. Still, I am learning, and that in itself is a bonus, a huge one! 
Like I said, even if you changed some settings in pamac-gtk (the GUI), e.g. enabled AUR, that is an edit to the pamac.conf file. That’s why only you can assess your own pacnew files since only you know if you had changed something previously.
@wongs - that’s pretty good advice, I think.
Personally, I did alot of modifications to my system, and after (almost) every update I check for .pacnew/.pacsave files with
locate --existing --regex “.pac(new|save)$”
(credits to unknown - I found it somewhere in the old forum)
If any file is found - which hardly ever happens (just my experience) - I try to deal with them immediatly basically by doing what @wongs recommended.
In any case I backup the new and the original files (on an external drive), and those files I didn’t handle will just sit there until I learned enough - either actively or passively to be able do deal with them appropriatly.
Before I do any changes of that kind, I make a timeshift backup (to said external drive), which in 99% of the time saved my sorry little butt.
If you’ve got an external drive and use it for backups - way to go - nothing to be scared of.
If not, use e.g. an usb stick for backing up important data, (config-)files, etc.
You can do it!
Thanks for that encouragement.
Backups are always taken on an external drive, I use grsync to sync files before updating. And then turn it off until needed. At any time, the drive is durned off.
I may need to consider a new drive, as 2Tb may prove to be “just about enough” lately 
I will need to find that timeshift backup and work with it. Seems safest to do it that way too
Yikes! What a ride!
Melissa
Timeshift can be found in the official repo. It’s pretty self-explanatory to set up.
If any questions occur - shoot. 
The common pacnews seem to be fonts and locale. I think everyone has probably altered them but luckily I don’t think there’s much in them that can break anything
I use Meld
I open a Terminal (Konsole for me)
and I past this:
#!/bin/bash
#Merge new .pacnew configuration files with their originals
pacnew=$(find /etc -type f -name ".pacnew") # Check if any .pacnew configurations are found
if [[ -z “$pacnew” ]]; then
echo " No configurations to update"
fi
for config in $pacnew; do # Diff original and new configuration to merge
kdesu meld ${config%.} $config &
wait # Remove .pacnew file?
while true; do
read -p " Delete “”$config""? (Y/n): " Yn
case $Yn in
[Yy] ) sudo rm “$config” &&
echo " Deleted “”$config""."
break ;;
[Nn]* ) break ;;
* ) echo " Answer (Y)es or (n)o." ;;
esac done
done
you have to be care, few .pacnew should never be merged, do a search in the old forum``
Well, that guy knows his way around linux
But beware that what was valid a couple years ago might not be today anymore. Make sure to check the comments on these videos. If in doubt, have a look at the github page, specifically the ‘issues’ section.
If ever needed, you can use terminal commands,
sudo timeshift --restore
is the one that usually saves me, chrooted and/or from tty…
You need to use the CODE tags around scripts and similar texts if you want to share them, currently it is useless as people can’t copy paste it
I forgot to update partner’s system until today
I got this message during package updates
warning: /etc/locale.gen installed as /etc/locale.gen.pacnew
so I compared it in meld alongside the original locale.gen
sudo meld /etc/locale.gen /etc/locale.gen.pacnew
and found 3 differences:
this is a new locale (Iraq)
it is safe to add this to the original file as it is commented out by the #
this is the active locale setting and must not be replaced with the commented out entry in the .pacnew file. if this setting was commented out, there would be no active locale and system would not be happy about that
this is old section left behind from Calamares installer
it is all commented out and inactive, so it can be deleted
