Hi all,
I think the title says it all.
Never worked with anything around it. Anything merging files and such.
I have a vanilla setup, XFCE straight out of the tin and no modding…
All in light of the oncomming update (PAM related especially)
Thanks
Melissa
2 Likes
How about the good 'ol Arch Wiki? 
https://wiki.archlinux.org/index.php/Pacnew_and_Pacsave_Files
3 Likes
Thanks. Any help is welcome. The prospect of a dead system after an update scares me as I dont know nearrly enough to repair things. I an chroot in a system and update things and so on, but I never worked with pacnew and such before…
Thanks
1 Like
We also have one
Really? … havent you been a manjaro user for years now?
You should have had a few over that time … were you just ignoring them?
2 Likes
I think this update was unusual due to the nature of the files involved and the pronounced outcome (failed login) if not dealt with straight away. It may have highlighted some manual intervention some have missed previously.
1 Like
Ehm, yes 
(blushing in shame) since I never change anything and all the software is stock-off-the-shelf, I though it not needed…
1 Like
Its definitely needed.
By default the package manager will not overwrite files that are different from the defaults
(such as something you edited, or that is particular to your system like language and password)
So instead of clobbering those files it makes .pacnew files.
In the (rare) cases it does it the other way around its a .pacsave file.
This just comes with the rolling.
It is the users responsibility to take care of these things.
If you dont … little and big bugs can pile up over time.
Some you may not notice, and some like PAM may be a near instant show-stopper.
So … here are some quickies:
List pacnews
pacdiff -o
And I like using meld … so to compare only view (hit v for each instance)
DIFFPROG=meld pacdiff
(of course you could set your DIFFPROG variable elsewhere and not need it here)
PS … here is an example of meld and a file you should definitely not merge or overwrite:
7 Likes
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
3 Likes
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.
1 Like
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.
11 Likes
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
1 Like
@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
3 Likes
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! 
2 Likes
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.
3 Likes
@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!
1 Like
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