You are not logged in.
I'm using paru to update the system when I run pacmatic. Some times I need to use sudo to replace pacnew files. However, if I always run pacmatic with sudo that causes issues when paru updates packages from the aur. So, instead I've appended sudo to the calls to functions calling $pacdiff_program. Is there a better means of handling this than adding sudo to parts of a script? Is there any means that would not require editing the pacmatic script to run vimdiff with different permissions from the rest of pacmatic?
Offline
the point is to not automate it at all - same as you're not supposed to run updates unattented
just replacing current configs with new defaults also can cause severe issues - instead you're supposed to check the difference and merge them properly
Offline
I'm hoping they are just using pacdiff for an interactive merging session.
Speaking of which, it does have a dedicated -s option so pacdiff will properly invoke sudo on it's own. And the underlying question, sudoing the distinct necessary parts that actually require this is the way to do it for scripts.
Offline
the point is to not automate it at all - same as you're not supposed to run updates unattented
just replacing current configs with new defaults also can cause severe issues - instead you're supposed to check the difference and merge them properly
I merge them manually after reviewing. pacmatic doesn't always play nice with paru, if paru is configured to update the AUR and Arch repos.
Maybe, pacmatic needs to be updated to not break if the pacman_program and pacdiff_program values are changed. I just put sudo before pacdiff_program calls. So, I can update AUR files, and have pacdiff delete the pacnew after I've edited everything to be the same.
Offline
I just noticed pacmatic is no longer in the aur? Can I just fork and add it back? Looks like the developer behind it is no longer involved with Arch.
All it is is a script that checks the news, and deals with notifying the user to update pacnew files and such.
Last edited by zerophase (2025-03-03 00:38:50)
Offline
then what's the need to run that as root anyway?
Offline
You can't delete the pacnew files without running as root. Pacmatic is script in Arch from like 16 years ago for adding a bunch of maintenance tasks every time pacman or an aur helper is run.
Offline
well, I have not experienced what might happen when a package ships a .pacnew while another from a previous update still exists - but I still fail to see a point where one would want to auto-cleanup any .pacnew file en masse
and even then I would either use something like
sudo rm $(find / -name "*.pacnew")
or would use a pacman hook
Offline
packages don't ship pacnew/pacsave files, pacman generates them when needed, see https://wiki.archlinux.org/title/Pacman … nd_Pacsave .
Pacmatic doesn't seem to have a license, forking it may lead to legal issues.
You have seen https://github.com/keenerd/pacmatic/issues/44 ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
packages don't ship pacnew/pacsave files, pacman generates them when needed, see https://wiki.archlinux.org/title/Pacman … nd_Pacsave .
Pacmatic doesn't seem to have a license, forking it may lead to legal issues.
You have seen https://github.com/keenerd/pacmatic/issues/44 ?
He has to send a cease and desist letter. If he does not enforce his copyright for a long period of time it is not a violation from the doctrine of laches. It would be ideal to get in touch with the original author, and have him place a license on the code, though. I just want to make sure if I put it up on the aur it won't get taken down immediately. I have some local modifications and wrapper scripts I might as well just add to pacmatic. It's all simple stuff writing hooks for would add more complexity than required.
Alright, so I just need to say I'm forking it on that issue and people can submit changes to my fork. If Keenerd ever comes back he'd just need to send me a cease and desist letter within a reasonable amount of time. It's not like I'm dealing with Google where they might spend millions of dollars defending a script, even if I'm legally in the right.
well, I have not experienced what might happen when a package ships a .pacnew while another from a previous update still exists
You misunderstand Pacmatic is script for reminding the user to do a bunch of tasks around package maintenance when upgrading. I ran into an edge case when using Paru to update the aur along with Arch packages I have to manually run:
sudo rm -f *.pacnew
It's since I'm running aur install commands without root privileges, so pacmatic does not have root permissions for handling dealing with the pacnew files. What I believe is happening is paru handles getting privileges properly for the aur and Arch repo, but the paccdiff command is not getting root privileges. Before paru I used bauerbill for the aur, and powerpill for pacmatic; so, the issue did not pop up. I was hoping there was a more elegant secure solution than just adding sudo before the pacdiff commands, which is what I've done.
Last edited by zerophase (2025-03-05 15:25:01)
Offline