ILoveCandy option has been used by some Arch/Manjaro users for many years
[Solved]No pacman in pacman![Solved] / Applications & Desktop Environments / Arch Linux Forums
option can be commented out if not wanted
3 Likes
I put that section in there.
Its the recommended way of handling pacnew files.
There was absolutely -Zero- communication with Stable branch that the community repo was being removed ā¦ explicitly reminding people of pacnews and how to handle them, specifically in this update context, seemed the least that could be done.
pacdiff is the utility for managing pacnew and pacsave files. This has been true for years.
pacdiff -o will simply print them.
pacdiff -s allows for prompting sudo when required, such as when editing or merging or removing.
https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave
Very old, semi-easter-egg ā¦ it makes the download lines in pacman appear ā¦ like Pac-Man (the waka-waka variety) with a yellow C eating dots.
The section not being commented out (as it is upstream) is probably an oversight of the packager ā¦ or maybe a jest.
Its a bit sad how many people are only getting acquainted with the basics of pacman (and package management in general) now.
But oh my - isnt everyone happy that pacman existed to be able to fill in for a broken pamac?
1 Like
If they have never edited it ā¦ and they are just going to accept the new file ā¦ without inspection ā¦ then they can do the blind merge just as easily ā¦ or easier with pacdiff.
ex:
$ pacdiff -s
==> pacnew file found for /etc/makepkg.conf
:: (V)iew, (M)erge, (S)kip, (R)emove pacnew, (O)verwrite with pacnew, (Q)uit: [v/m/s/r/o/q] o
(or you know ā¦ they can use that same interface to view, then overwrite, manually merge, etc)
IF users have not previously set DIFFPROG and/or cannot use vim -d then they may wish to temporarily set it to something, like:
DIFFPROG=meld pacdiff -s
Im actually not that sure if pacdiff (that requires vim) is the recommend way to handle this stuff.
I prefer to use the tools that i have and already can easy use, like go in the folder and open both files with kate and compare that stuff and if im okay with that changes i will just copy the full text or a single line from pacnew to the original file and just save it.
Im actually think that this wiki article makes pacnew and pacsave files unnecessary complicated, and most of the time this files can just ignored, but it can maybe help and solve problems after a update when a application has some problems. (Maybe we should keep that in mind)
Instead the article said, that we should always deal with it, manuallyā¦ which normal user has the time to always compare this .pacnew or .pacsave files after every single update? I dont and i think it goes the same way for atleast 80% of the community here.
It is.
You can keep disagreeing if you like ā¦ but thats the tool for the job.
See the linked wiki.
You can manage them some other way ā¦ such as by inspecting them yourself ā¦ but its just going to take longer and have less security/stability (pacdiff manages the permissions properly for example).
And it does not require vim -d or vi or vim ā¦ it just requires some diffprog ā¦ if users have not configured one ā¦ it defaults to vim -d ā¦
This is something that could be changed at the package level ā¦ but as the fearless leader mentioned they have never used pacdiff ā¦ it may not be likely to happen.
Like that.
Thats an example of using the wrong tools in a more roundabout way. But you can do it if you like.
Thats just wrong. You cannot ignore them forever. Things will break.
Things will also likely break if you just blindly overwrite with every new file.
/etc/default/grub would be one such file ā¦ /etc/shadow would be another ā¦ if you just automatically overwrote those files with the new upstream one ā¦ you would face a black screen at next boot.
If they dont ā¦ they should wait until some distro introduces some auto-magic way of doing it ā¦ or use something else. Its simply inescapable that you must manage pacnew/pacsave files on an Arch based system.
I guess I will leave this hereā¦ one. more. time.
Atleast i ignored that files for around 3 years now (successfully), since i installed my Manjaro (07.2020) and joined the Linux community. Till today, i have no problems and my PC and my Laptop running stable with Manjaro KDE.
Some sort of combination of luck and lack of configuration on your endā¦
A sort of happy accident that lack of knowledge to fiddle around ā¦ meant you didnt do something like automatically overwrite grub with the upstream file, and similarly that you didnt have some xorg configuration you needed to keep intact while merging changes to work well with an updated mesa software.
Likely though that would not last foreverā¦ at some point major changes would come to something like mkinitcpio that you might refuse to merge ā¦ and then ā¦ at some point you dont understand why your hooks that fire after installing/updating a kernel dont work anymore.
I mean ā¦ this is an example right here. If these changes were never merged ā¦ you would still have a defunct community repo your system would be trying to use.
No, heās right. Iāve been using Manjaro for 18 months, Iāve seen pacnew files for grub, mkinitcpio, httpd and more, but none of those ever contained anything that would cause breakage if not merged.
So Iām pretty certain that a very large number of Manjaro users donāt manage pacnew files at all, they just ignore them, and that works, for a very long time. And because it works there is no incentive for them to learn this stuff. And then suddenly one day it doesnāt work and itās their fault for not knowing.
Btw pacdiff -s doesnāt work on a standard Manjaro install because it doesnāt have vim (and vim is a terrible choice of merge tool anyway, IMHO 
).
2 Likes
Iāve ran into this problem before with Manjaro updates, which is why I installed TimeShift, and set it to back up root (system files) + hidden files in home (settings files) only, and do auto backups once every 2 weeks only, and keep last 2 backups only. That way, I can undo any Manjaro update, even if Iāve been using it a few days. The most Iāll loose is 2 weeks of emails; but those are saved on my email servers, so that problem fixes itself 60 seconds after launching Thunderbird.
However, if you donāt have TimeShift (or similar system) set-up to back-up your system every week or two, and if you didnāt make a manual system backup before updating, and if you experience a problem after one of these massive Manjaro updates (āyou have 947 available updatesā), and if problems arise (and they probably will), youāll have to fix them by tracing each problem to its source and fixing them piecemeal, because wholesale ārevertingā will not be available to you, because you wontā have anything to revert to.
So, Iām grateful to TimeShift (and to myself for setting it up the way I did); it already saved me once early today when I managed to destroy my āpacmanā package manager. No problem, I just reverted my system to how it was on July 5, 2023, and everything worked. So I strongly recommend installing TimeShift and setting it up as I describe above; it wonāt help you this time if you didnāt already have it setup and running for several weeks, but it will certainly help next time a problem arises.
1 Like
Everything you said has been addressed already. Iām done repeating myself for the day.
I guess I can leave a less verbose, but manjaro-specific, linkā¦
https://wiki.manjaro.org/index.php/System_Maintenance#Pacnew_and_Pacsave_files
Ya, donāt do that. I tried that earlier, and not only did it not fix the problem, but it destroyed my pacman (was giving āno such package existsā errors for every package, including pacman itself). I was able to restore functionality by TimeShift-ing my system back to July 5.
And I was able to finally do this update. The key was to update my ālibpamacā (I think it was from 11.5.5 to 11.5.7 if I recall rightly) by becoming root and typing āpacman -Sy libpamacā before updating anything else. Then I became root and typed āpacman -Syu blasā (to bypass the cblass bug) and manually intervened several times (to bypass the python-faust-cchardet bug), and everything installed correctly.
Though I can immediately see one post-update bug: when rebooting, when I reach my graphical OS log-in screen, select user, and type-in password, I have to wait 60 seconds before clicking the arrow button or hitting Enter; if I donāt, the system freezes forever on the splash screen. Hopefully thatās the worst of the bugs, but weāll see; after such massive updates, problems often crop up a few days later.
After finally getting the update to work (I had to separately and manually update my libpamac first, that was the key), I have the issues 2 and 3 that you list. The tty2 thing I donāt care about, as thatās how Manjaro-Mate (and presumably Manjaro-Gnome) do it anyway. The āmust delay 60 seconds after typing password before hitting enterā bug is a bit more annoying, but ultimately not a huge deal. I just hope there arenāt worse bugs that I havenāt discovered yet. After these huge Manjaro updates (āyou have 947 updates availableā) there often are.
1 Like
Sometimes, you need to combine pieces from the new and old files to make everything to work. In these situations it is better to integrate the files manually.
Thatās the Manjaro-specific advice. It doesnāt recommend pacdiff -s at all. I do use that command (with Meld) but if someone else is more comfortable integrating files with other tools that they know better then Iām not going to lecture them on what is the best tool for the job.
The manjaro-specific advice there says āintegrate manuallyā ā¦ meaning, in opposition to blindly replacing.
It means that you should compare them.
Which pacdiff facilitates ā¦ that blurb there is roughly just the pacdiff help information.
Beyond that it is more of an introduction - then encourages you to see a better guide at ā¦ oh yeah that arch wiki article.
Users have the ability, and often should have a number of environment variables set - among these are DIFFPROG, SUDO_EDITOR, and a few others.
Without DIFFPROG defined pacdiff automatically attempts to use vim -d.
If users have not done so, but wish to use something else nonetheless they may use the env var:
DIFFPROG=meld pacdiff -s
But ā¦ sure ā¦ do it manually if you really must. Nothing is stopping you.
Still - the best tool for reporting them would be pacdiffā¦ pacdiff -o.
Youāve moved the goalposts a bit ā¦ stepping back from āthey dont need to be managed at allā to āpeople can use whatever toolāā¦ which I suppose is progress, even if it still belies some fundamental misunderstandingsā¦ including that you can use any given comparison tool with pacdiff, or, even use the tool to simply delete every pacnew.
@cscs youāre just wasting time on ignorant people. And in some time, when they open a new topic āxy brokeā, you (and others) will be wasting some more time trying to troubleshoot something that broke solely because of user (in)action.
And thatās what happens when you are enabling users with spoon feeding everything - on a āuser-friendly and suitable for those new to computersā distro. 
1 Like
Yeah, its probably better to not help ppl, giving the distro a reputation of being not particularly user friendly.
Sounds great!
You sound very bitter.
Yes, I agree spoon-feeding people shouldnāt be done. However, I donāt think itās Manjaroās fault that people donāt want to think.
I think thatās societyās fault in general. And Windowsā.
Butt, hehe yeah - I said it, Iāll keep my yap shut as this isnāt a forum, never mind thread about lifeā¦
Thatās just plain luck. Youāre lucky. Nothing else.
From experience I will say that at some stage that luck will run out.
Another day, another question.
With the latest update (libpamac 11.5.7-1) pamac GUI seems to be working fine, at least I can see core, extra and multilib repos populated with packages.
But thereās no any trace of AUR repo and itās packages. Of course I have AUR support option enabled.
Is it supposed to be like this?