Exists already for existing tools …
The hook itself is not the issue. 
Then … I dont know what is ?
You use the same hook in the same way but modify the exec (in delta):
diff -u "${pacnew_path}" "${modified_path}" | delta
Definitely not, until you make it 100% “safe” to click randomly in it (see my previous post)
2 Likes
In fact, this is the most frustrating work to do after each upgrade operation, in addition to those new additional packages.
It would be great to have this utility to start after all upgrades are finished, but the problem is that upgrading can be triggered via multiple tools: pamac gui, pamac cli, yay, pacman…
For Pamac GUI, the perfect solution would be to have the whole erasing, comparing, merging, editing operations inside Pamac interface, so after all upgrades are finished, a new pop window appears with full list of all new pacnew files that needs user intervention, at this stage the user can select what to do with each item, for comparing and merging an external tool like Meld can be invoked.
12 posts were split to a new topic: Pacnews - misconceptions and miscommunications
You don’t have to do anything; with this tool when a new pacnew/pacsave is detected you will be shown the warning and you decide what to do with it.
2 Likes
The biggest problem is that some changes in configuration files, related to sensitive packages like grub, systemd…, can break the whole system, so this popup window should appear at the end of upgrades to tackle any urgent modification before the user attempt any reboot.
Running it as background service with interval checks can fail to trigger the detection if the user directly reboots the system after all upgrades are finished.
2 Likes
This is a good point… Maybe I can work around this by creating a pacman hook which creates a pilot file when pacman creates pac* files. Systemd path will take care of monitoring this file and if it sees it modified, launch the GUI program (always at user level). Note that all the effort is not to redesign pacdiff but to have a minimal GUI that mimics its features.
3 Likes
Here’s just a stupid idea… What about a notifier icon in the system tray that, when clicked, brings up the application via pkexec? Because actually merging the .pacnews is going to require superuser privileges anyway. 
1 Like
Well manjaro-pacnew-checker is at version 0.3.1. Now checking is in real time via a ALPM hook + systemd
5 Likes
I’ll install, use, and give feedback later.
What about the safeguard idea? As I explained, there are .pacnew files you don’t want the “normal user” (also called the noobs, or worse) to mess with, without at least warnings or something else that will prevent them to break the system. Especially if you had the idea to add this tool to other Majaro main tools, many user will destroy their system (it may be better they don’t touch .pacnew file rather than destroying critical system file by replacing with .pacnew).
I agree, simple way Is to add a disclaimer with the link for ask on the forum what Is best to do with the pac* showed and in the meantime i change also the default choice to “nothing to do”
2 Likes
Safeguard would be to have a warning in post #1 of release announcements:
so the warning is also visible in announcements by email, RSS and social network feeds
1 Like
So nobody who needs to see it would see it. The people who need to see that don’t go to the forum let alone read the announcement threads.
And that is most likely already the case, important config changes are usually announced.
1 Like
There was no warning about /etc/pacman.conf.pacnew in post #1 of Stable update 2023-07-10
And even people with reading abilities seem to have overlooked information posted by @cscs in post #2 about merging /etc/pacman.conf.pacnew.
Many more posts than usual from new users and ‘been a while since…’ users
No surprise considering it has been a while since users on stable branch had to deal with a .pacnew file
2 Likes
Sure there was. See The community repository has been merged into extra and is now empty
1 Like
And that’s adding to my point. Having the info in the forum is useless anyway for these non technical people, the safeguard with this tool should not be a message in the forum but something in the tool itself.
And about this pacman.conf file it is not what I call a critical system file, replacing it with the pacnew is completely OK.
Now replace shadow.conf with its .pacnew and see the result 
1 Like
Which posits a very serious question regarding what demographic Manjaro is for.
As I see it, Manjaro, by virtue of being Arch-based, is a distribution for people willing to assume the responsibility of maintaining it as it should. It is not — and, again, by virtue of its origins as an Arch spin-off, cannot be — a household kitchen sink appliance for consumers. They would be better off using a distribution designed to be used that way — something like Ubuntu.
The user cannot have it both ways, and as the supporting community, neither can we. Either we stay true to ourselves and to the nature of Manjaro, or we turn it into yet another clone of Ubuntu, Mint, or whatever else is out there.
There are already plenty of people out there who install Manjaro and then don’t update their system in years. And for that matter, do we really want to turn Manjaro into a distro for hardcore gamers at the expense of the community of helpful volunteers and the quality of the distribution?
8 Likes
Who knows what lurks in shadow.conf.pacnews?
The Shadow knows…
…I’ll see myself out…