I would expect something like “command not found” in that case … the empty output makes me believe pacdiff is there, just producing nothing (nothing found).
But it might be worth checking.
1 Like
Yes, so would I, but it is possible that OP uses a non-verbose shell — which in and of itself would be peculiar, and certainly not a Manjaro standard, of course.
Aye. One never knows. Quantum uncertainty, and all that jazz. 
Somehow I missed that notice about COMMUNITY and it caught up with me today. Minor inconvenience to sort it out. Oh well…
Indeed there are entries for a pacman.conf.pacnew from for example January, February and October 2024 among a long list of “running pacnew-checker.hook” messages and other pacnew files. Seems i indeed failed to remove the community entry as i should have when pacnew-checker was giving me the hint 
.
pacdiff exists on my system … i checked it.
It still shouldnt have meant that the pacnews got removed.
They are there to be actively used to compare.
Were they removed through manjaro-pacnew-checker?
With all due respect,
This wasn’t a breaking change until the user, the administrator, the person responsible for the computer, did not do proper maintenance, like is expected.
Do you do maintenance on your car? If you don’t have one, you do realize that maintenance should be done on it right? Why not your Linux, that you arguably use more than you car? Or more than the average car is being used?
It’s not any distributions fault if it breaks because proper maintenance was neglected. If you don’t maintain and/or service your car, it’s going to break down…
1 Like
I totally agree with @tdussa. This is not a car, it does not require pieces replacement. It is a bad comparison, from my point of view.
I don’t think that the comments from @tdussa are destructive, but constructive. I think that people should want to do things better each time, enhancing the debilities to have a much better operative system to all of us.
Of course, if the point of view of this issue is that there is not anything to do better, I am now sure that I will search for a different linux distribution, focused to easy my work, and not to get stalled in the past. I really thought that this was not the target. Perhaps I was wrong.
Thank you for your attention, guys.
1 Like
Not physical pieces, or parts, no. But maintenance, none the less.
Yes, I realize that is the general process. My question stands: In this particular case, what is the showstopper that does not allow for an automatic removal/commenting out the references to the community repo entries in the pacman config file? People keep saying that it’s all my fault that I tripped over this because I failed to do proper sys maintenance, and I do not deny that, of course I could have avoided the issue. However, IMHO it is good system design to automate as much as possible (note that this means that if automation in this case is not possible for whatever reason, then so be it – that’s exactly my point). And if it would be possible to automate it, well, even then, of course, it is totally up to the Manjaro maintainers to choose not to implement such a solution. I would just like to point out that that would unnecessarily make things worse (or, well, not as good as it could be) for a lot of people.
So far, I haven’t seen a good argument why this particular change could not have been automated, just a lot of fingerpointing and telling me that I’m doing a bad job administrating my systems. That may be true (or it may not be true – all you know is that I missed this particular bump, but it doesn’t matter anyway), but it has absolutely no relevance to my question.
Also note that IMHO the entire “automatically changing config files is hard to do right” line of reasoning is moot. That’s a killer argument that does not address the particularities of this case. Sometimes there are changes that are not hard to do right, especially if the alternative is to break a working system for a lot of users. It may well be the case that there is some good reason that commenting out these measly two lines of configuration comes with technical problems that I fail to see – hence I asked here --, but I cannot think of any reason not to do that automatically, at least for the default-config case.
1 Like
It is the policy and procedure that NO updates should ever touch system configuration files.
Not automatically.
Instead, the changes are announced and provided through these .pacnew files.
Not tending to them immediately will usually be of no consequence.
But ignoring them over a period of time will eventually lead to problems.
This one particular change could, presumably, have been handled automatically.
But it would still have been error prone if the file was not in it’s default state.
In other cases - not so much.
The car analogy is actually quite a good one - in the case of Manjaro/Arch, you are (through quite frequent updates) actually gradually but constantly changing every part of the car over time.
… kind of a “forced” parts replacement … requiring a recalibration of some modules now and then …
That’s fine. Rolling releases require active maintenance by system administrators, and not every user wants to, or is able to, spend 5 or so minutes of their time each month doing that.
2 Likes
pacnew-checker should alert user when a .pacnew file is created so user can either:
- compare files and merge data
- replace .conf file with .pacnew file
- ignore .pacnew file
- delete .pacnew file
I’m not a beginner user, of course not (many years working in Linux, different distributions).
The issue is not being a beginner, nor that there has been a one-off failure. The issue is the attitude that is shown to hear users and try to become better and better, which has been shown to me to be a zero attitude. This should not be the point of view or the correct answer, but rather studying how it could be done better in the future.
I see now very clear your position, and of course I will look for a distribution with a better attitude for the future.
It probably could have, but there’s a system in place to prevent breakage.
Maintenance is required for most things, we can often ignore it for a while but eventually it needs to be done or things will break.
I think you’re looking at it wrong.
It’s better to have a single system that prevents breakage, than to try to automatically merge some of them in a way that could break things (eventually something will go wrong). Besides there’s enough work for the devs as it is, they could do without creating a new script every time a config file is changed.
In addition this change is actually very easy to implement, so it provides a good introduction to managing .pacnews. If all the easy ones are done for you, then it makes .pacnews even more intimidating to new users and the learning curve steeper.
2 Likes
Manjaro maintainers will not intervene on a system maintenance issue
“your system under your control”
but they do provide tools and information to help users maintain their systems
System Maintenance - Manjaro Wiki
This article contains tips and best practices for keeping your system in optimal condition.
Manjaro forum has many warnings and information about merging pacnew files.
First post in update announcements may have a warning if a .pacnew may cause a critical issue (but package manager failing to synchronise with a defunct repo is not critical and simple to fix)
2nd post Known issues and solutions in update announcements has a general warning
There are also many previous forum posts over the last 2 years where users have spotted a package manager syncing to defunct community repository. And other posts were new users asked about managing other .pacnew files
2 Likes
Yes i think i got an alert for the pacnew file and then i can compare both and decide what should happen … i fear i opted back then to keep the community repo and then delete the pacnew file, because i think if you keep the pacnew file you will be alerted with next update again…
… which would be "a good thing"™ - preventing you from just forgetting about the potentially critical issue …
My pacman.conf file does not have a community repo reference and I don’t seem to have any residual .pacnew files. I get either on pacman or pamac the reference to the missing community.db files. Beyond the pacman. conf file where else does this update requirement lie?
Thanks for all your help
1 Like
Indeed it is a good thing … helps me clean up the pacnew files as soon as they pop up … doesn’t help if i mess up though ;).