Hello,
I noticed that many people don’t know about pacnew files or at least don’t pay attention to their creation during the upgrade phase. To help even those who don’t pay attention, I created a bash script with yad GUI that simulates pacdiff actions.
The program runs in the background and opens when new pacdiff files are found. Maybe it won’t be the best approach but if anyone has other ideas they are welcome.
I can’t… this is already suggested by @Yochanan in our private chat but for security reason, i can’t open a GUI during the upgrade via pacman hooks because it is open at the root level. This script runs in background and checks any 10’ . This is only a starter, we can always do better.
Makes kind of sense yes. Although I’m sure there is a way…let me think…
Edit:
I’m guessing it won’t work to run it with sudo -u?
$ manly sudo -u
sudo, sudoedit — execute a command as another user
==================================================
-u user, --user=user
Run the command as a user other than the default target user
(usually root). The user may be either a user name or a nu‐
meric user-ID (UID) prefixed with the ‘#’ character (e.g., ‘#0’
for UID 0). When running commands as a UID, many shells re‐
quire that the ‘#’ be escaped with a backslash (‘\’). Some se‐
curity policies may restrict UIDs to those listed in the pass‐
word database. The sudoers policy allows UIDs that are not in
the password database as long as the targetpw option is not
set. Other security policies may not support this.
There is definitely the need of it for new users, that only click on “apply” in pamac and don’t read the log. We have the Manjaro Notifier to notify for unsupported kernels, pacnews are just as important as we saw with the removal of the extra repo. So for me this actually belong there in the long run. On the short term i think this should be shipped and enabled by default on new installs. Even if it is only in english for now.
We actually discussed it recently here
Congratulations for the script, if looks very nice. My 2-3 cents @Ste74 when i look at the source:
isn’t 10 minutes a bit too frequently and waste of CPU? At least make it an hour or so?
meld and yad are not installed by default, i hope you marked them as dependencies (cannot check my mirrors seem not to be updated yet)
From the screenshot I already have a few suggestion if you don’t mind.
You probably should add safeguards for some of the configuration files, I’m thinking about the /etc/shadow config file or some similar critical system files that should not be overwritten without knowing the consequences.
Maybe add a group of hard-coded files, some sort of list that could be expanded in the future, that will not be treated the same way, so it is safer for the normal user who usually click “next next next” (maybe remove or change options available).
The “conflict” term is a bit strong to my taste but I guess this is a whole discussion for a point of detail in the end.
So the idea is this should be running always and relies on that sleep loop?
Why not use systemd+timer ?
Also … why does it specifically ignore pacsaves? They can be important too.
More typos also:
# The user has chosen to opening the diff files.
(better would be “The user has chosen to open the diff files” except … they arent diff files … so its somewhat misleading.
A bit like the next text issue:
Management of configuration conflicts completed.
There arent really conflicts.
Oh, and, it should be mentioned that the admin:* bit you are using in meld is a function of gvfs … so that would need to be a depend too.
( I would know … because this approach is directly lifted from my fork I shared here )
Was my first attempt but yad can be called from a systemd service? Is an admin ( root ) service right ?
Right pacsave can be managed also… and yes my english is bad
First - systemd user units exist … and second - theres nothing saying you cant use sudo -U
(remember sudo is not equivalent to “super user do” it is more equivalent to “do as” … and that can be any user)
EDIT
And heres some more food for thought.
Sorry for the tome … it looks bigger than it is because of quotations.
I should clarify again that pacdiff -s accomplishes this already quite well, which is why I eventually considered the fork unnecessary.
While somewhat less than intuitive … the ‘view’ option of pacdiff indeed works as ‘view and edit’, while -s is not simply ‘pass sudo’ … its rather sudoedit … meaning it handles permissions properly and is acting on temporary files and uses sudo afterwards to apply changes.
man pacdiff
[...]
-s, --sudo
Use sudo and sudoedit to merge/remove files.
[...]
[...]
-e, --edit
Edit one or more files instead of running a command. In lieu of a path name, the string "sudoedit" is used when consulting the security policy. If the user is autho‐
rized by the policy, the following steps are taken:
1. Temporary copies are made of the files to be edited with the owner set to the invoking user.
2. The editor specified by the policy is run to edit the temporary files. The sudoers policy uses the SUDO_EDITOR, VISUAL and EDITOR environment variables (in that
order). If none of SUDO_EDITOR, VISUAL or EDITOR are set, the first program listed in the editor sudoers(5) option is used.
3. If they have been modified, the temporary files are copied back to their original location and the temporary versions are removed.
To help prevent the editing of unauthorized files, the following restrictions are enforced unless explicitly allowed by the security policy:
• Symbolic links may not be edited (version 1.8.15 and higher).
• Symbolic links along the path to be edited are not followed when the parent directory is writable by the invoking user unless that user is root (version 1.8.16 and
higher).
• Files located in a directory that is writable by the invoking user may not be edited unless that user is root (version 1.8.16 and higher).
Users are never allowed to edit device special files.
If the specified file does not exist, it will be created. Unlike most commands run by sudo, the editor is run with the invoking user's environment unmodified. If the
temporary file becomes empty after editing, the user will be prompted before it is installed. If, for some reason, sudo is unable to update a file with its edited ver‐
sion, the user will receive a warning and the edited copy will remain in a temporary file.
[...]
…meaning … that there is not a reason to make all of these extra functions.
If you need/want to add yad or other graphical notifications and/or buttons then go for it.
But pacdiff -s alone will handle all of the pacnew/pacsave and permissions and editing and so on … so long as DIFFPROG is set to whatever your preferred editor is. If set to meld … then pacdiff -s will do what this utility does, but better (just without the graphical prompts) … so I humbly suggest you revisit this with these things in mind …
Once again:
yad = ok
circumventing pacdiff for no good reason = less ok
I try to run this function after a big update, and handle the pacnew files then.
But at the moment, I don’t understand how to exclude path’s out of a find command.
Well manjaro-pacnew-checker now is at 0.2.0 version and i have correct my bad english, pacnew and pacsave are listed and i switched to a systemd service. Now any 3 hours the check start.
I’m thinking of adding the service to some program like pacman or manjaro-system to make it reach even the old installations. Toughts ?
Personally, I wouldn’t do that. Have it running as a pacman hook after updating, yes — that’s where it matters — but I for one wouldn’t want to have it running as a timer.
)
Use AI to dumb it down even more. The future.