Pacsave, pacnew - how to manage those reasonably?

another idea to consider, make a backup copy of your original file before any merge attempts

not needed, because:

1 Like

I wrote 15 days ago a gui (qt), it available in aur pacnew-chaser


  • 2 backup systems

    • global: everything in one archive
    • the 2 files .bak just before edition (in git directory ~/.local/share/pacnew-chaser/)
  • use meld, diffuse, kompare or others (vs-code,...) loaded by polkit

  • show man (if exist) in web browser

  • F8 key for change icon color

No pacnew for test ? :+1:

sudo touch /etc/fstab.pacnew

do not create a test.conf.pacnew file because it only searches in the pacman database!


Nothing to do :wink: in moment.


  • white letters on light grey background
not KDE :) ->xfce

Thx for sharing :slight_smile:

Perfect :slight_smile:


Very nice! Will it notify the user after an update?

It is between the update text

( 8/30) Aktualisiere pinentry                      [######################] 100%
Warnung: /usr/bin/pinentry installiert als /usr/bin/pinentry.pacnew
( 9/30) Aktualisiere libgusb                       [######################] 100%

or in Announcment

1 Like

yes, I am thinking of new folks using pamac or octopi to update, a pop-up notification would be a help.

I suppose it's possible and simple with a pacman hook and a call to notify-send if a pacnew is present ..

EDIT: writed , for next version ...
in $HOME/.config/pacnew-chaser.ini, add :

# time of notify , 0 for not use



A crontab, we need more crontabs :wink:

1 Like

I posted the way I do it a while back. I have an update alias that checks for new .pacnew/save files after performing each update. If .pacnew/save files are found it writes a file to the desktop with their locations so that you are aware of them being present.

I'm not claiming its a perfect solution, but I like it, and it works for me .

1 Like

I tested already few solutions. Vimdiff is out of the way as I don't have and don't use vim. Dotpack is not clear enough about showing the differences in cli so I rather stay away from it. Using Kompare can do the trick but I can't figure out some of the gui markings and how does it works, despite reading about it, a bit too strange so no thanks.

I installed this meld and pacnew-chaser and it seems to be the best solution so far, big thanks @papajoke :

  • it shows pacnew files so I don't have to search for them and I have a list what is to do
  • it creates backup files automatically - saves time and introduce order, nice!
  • it opens meld seemingly with marked changes, it's enough clear to know how to use it without messing much
  • pacnew-chaser gui and prompts are Qt so they look well in Plasma with Kvantum theme, so that's bonus
  • and some more, need time to experiment

I will be investigating further pacnew files. Many of them seems to be very sparse. Old configs have lot of info and examples, while pacnew files are often few lines... and nothing more. Especially with nvidia and other gpu settings I must be careful, so many old configs seems to be better or more correct then pacnew's.

OK, after some pacnew-chaser I come to conclusion:

Pacnew files cannot be easily determined as better in overall, because of various situations:

  • confs often contain important settings for current system and pacnew are just blank, for example pssdw or groups file, that contains just root entry and none of the system users/groups, it cannot be and shouldn't be merged in any circumstances
  • sometimes we used personal settings, like setting an unstable or testing branch for pacman-mirrors so default pacnew file doesn't reflect that
  • some pacnew files indeed have new options that come from new kernel features like with TLP, so it's important to update those and yet don't update personalized blacklisted devices and some other non-standard settings that were changed (often not directly in conf but by commands or different system tools)
  • some pacnew have just updated hashed descriptions so merge all the way
  • some pacnew lack of description and are in more raw form then the current ones, so it's good to keep old ones hashed lines for better understanding what is happening in given conf
  • and some more various sitiuations

It takes lot of time and sometimes research to asses whether I should change something or not and documentation is not always clear enough. Still, such tools as pacnew-chaser and meld help tremendously in that task. Previously I compared files by opening both of them, snapping them to the sides (left and right) on another virtual desktop and look trough. As you can imagine, this is troublesome and not well effective.

However, I found some issues with pacnew-chaser. Sometimes after editing files in meld, pacnew-chaser seems to be frozen and unresponsive and I have to shut it down forcefully. It happens pretty often. Will investigate what is happening.

I have found the above command can take a very long time if you have large drives mounted in fstab, as it searches everything. It will also return hits on pacsave files in your mounted drives where your backups are stored.

I find the command below is my favourite for listing the pacnew files. Find, list, and save a log of newly created pacnew & pacsave files - (mlocate must be installed for this command to work).

sudo updatedb && locate --existing --regex "\.pac(new|save)$" > ~/Desktop/pacnew.log

no pacoring since pacman 5.0 :wink:

pacnew-chaser find pacnew (not pacsave) only in pacman database

for pn in $(LANG=C pacman -Qii|awk '/^MODIFIED/ {print $2".pacnew"}'); do
        [ -f "$pn" ] && echo "$pn"

pacman create a pacnew only if the file is marked modified ; the list is short so quick search

1 Like

Oh well that explains why I had it edited out originally. When I went to post it I thought I'd made a mistake and added it back. The old memory fails me too often. Good catch thanks.

I will edit it to remove the orig search.

@papajoke, I noticed that pacnew-chaser hangs after closing meld. It may take couple seconds or even a minute or more. If I opened the program from terminal, usually switching focus to terminal and focus back on the pacnew-chaser, it is unblocked, alas not always. Or maybe is that only a time depended behavior? I don't see any error outputs in terminal during that freeze. Seems like waiting is solving that freeze eventually, although it's hard to tell how long it will take this time. It's a bit weird. Do you know anything about it?

Since 2 days, pacnew-chaser have 2 modes : modal or not for load editor. too young to get good feedback...
Default mode is modal: wait (freeze) the end of the edition for only (at the present time) send destop notify if md5 files are different

for pass "no modal" , in $HOME/.config/pacnew-chaser.ini


I created another alias that will open the pacnew files in Kompare to merge them.

alias pacdiff='sudo -H DIFFPROG=kompare pacdiff'

When prompted in the terminal to edit the files simply select the "View" option and it will automatically open the 2 file versions side by side in Kompare for merging.


All roads lead to Rome. :slight_smile:

1 Like

I use pacui with the maintanance option.
It clears up old packages from cache, checks for broken symlinks AND calls pacdiff in the end.

I see pacdiff as great way to learn about new features about the software. Like hell I am going to follow every system components release logs. So new lines in configs = new features.

If you are not merging continuously, then after years the pacnew is changed so much that merge is difficult to navigate or understand.

System worked fine that is due programmers tend to keep their software work with legacy configs just because not everyone has time to merge or even wants to do so.

They can be major changes that breaks Arch or Manjaro so I do have time for merging just to be sure system crash in not my fault but the software's.

There are plenty of configs file that sits in $HOME that are never checked towards their recent counterparts. If anyone has an Idea (before I start to code something in python) how to check differences in your local configs with their etc originals, I would be greatful.

1 Like

Forum kindly sponsored by