Its linked from pages like pacman overview and pacman-mirrors … but it could be placed better.
The wiki needs an overhaul.
And thats currently happening - it is still in the process of being rebuilt.
1 Like
These efforts are really appreciated, thanks!
Late to the “party” … However, I had the same issue, and I assume it was due to the transition of Plasma 5.19 to Plasma 5.20 doing things differently. So that update sent Latte Dock to ?wherever?, changed the wallpaper to default and the panel configuration to default as well.
I assume that it is due to the implementation of the telemetry option that KDE implemented with the 5.20 series that inter alia extends (optionally) to give KDE info about your panel configuration …
Thus, my assumption is that we won’t find the “issue” in a .pacnew file.
Update.
Since my last posting in this thread, there have been two new Stable updates. I intended to wait a few days on the 2020-12-31 update, but installation of a new package sort-of forced it on me. Ooops.
Anyway, I performed an update in early December. My KDE panels got shuffled around and Firefox suddenly started having stability issues (screen redraw) which extended beyond FF to the rest of the desktop. Just killing FF didn’t solve the issue and neither did a log-out/in cycle. Required a reboot. I have not logs to show or video of it in progress.
The 2020-12-31 Stable update did not nuke my panel arrangements for the first time in months! Hurray!
Still having firefox issue mentioned above, though it is less troublesome. Restarting FF makes it stop and, even while actively suffering redraw troubles, it stays confined to the virtual desktop where FF is resident. This is not one of the many AUR builds of FF. This is FF 84 from the official repositories. This instability is only a minor problem; really little more than a reminder that I should restart and refresh the thing anyway. I have a terrible habit of leaving it active for days if not otherwise forced to shut it down.
Anyhow, that’s my update. Things are better, but also worse. I don’t know what changes happened to make things different but I do appreciate the time the devs are putting into their work.
I still don’t know what to do with pacnew files. The wiki unclear. I’m still ignoring them, pending better documentation.
1 Like
Basically .pacnew are new standard config files, since the new files might contain new parameters that need to be set, for the system to stay functional in that moment or in a later update, where those parameters are made mandatory to be set. Otherwise your personal config might need to get overwritten to make sure your system remains bootable/functional.
What they contain though depends on the program they are used by.
So it is wise to take care of them sooner rather than later.
Yeah. I had a second think about it and walked through handling them. There were some I was uncertain how to deal with. I didn’t want to overwrite my mkinicpio.conf with the pacnew just for switching " pairing to () pairing because it would also have overwritten my (system installation auto-created) disk and pagefile crypto! But also I think I probably do want that () pairing going into the future. I am uncertain how to handle this one, in particular. Most of the others were just changes to default comments in the otherwise default files and I would think pacman (pamac?) should have figured those out on its own.
(edit: )
That is to say: I thought pacman already had logic enough to figure that out on its own.
1 Like
You know you can simply edit those files manually right? That is always an option. Learning a tiny bit of Vim also helps a great deal, as it is normally the editor used by pacdiff. Otherwise you always can use diff to check for differences and sudo nano to use the easy use terminal editor to change what you think you should change. Mind you, you are the administrator for your system, as such it comes with full control over it, but also with the according responsibilities.
And yes, more often than not one can simply delete pacnew files as they are only minor changes. Still important to check first though.
In this case though i think you should be able to leave it as is for now without any problems.
1 Like
Seeing as how the topic has drifted away from my original complaint about doing wonky things to my personal configs to handling pacnew files and how there is insufficient documentation on pacnew files… Where do I go to add a small bit about pacnew in the user manual that comes with new installations of Manjaro? My thought is just to add one or two sentences of intro and then link to Arch’s wiki.
I know, I know. Gotta remember which files are which. I should’ve kept an open *scrach* buffer in emacs…
I also need learn a lot more about diff and merging changes, in general.
There is such a page for that already… seems it isn’t indexed well by google though.
https://wiki.manjaro.org/index.php?title=System_Maintenance#Pacnew_and_Pacsave_files
1 Like
Yes, and that’s the wiki; not the PDF user manual that comes with fresh installs of Manjaro.
Also, pamac does a really poor job of notifying a sysadmin to check for .pac* files. It is especially so in the pamac gui. This means new users (and even old users who haven’t had any issue where a .pac* file could solve) have no idea even to bother looking at them, let alone how to deal with them.
Yes, there are errors, warnings, and notices buried deep in the long long string of text that happens with most system updates (cli)(might as well be invisible in gui due to being on a separate panel that many wouldn’t even know how to open because the > indicator is tiny and tucked in a corner). And that’s the problem. pacman and pamac errors, warnings, and notices are buried rather than collected and presented in an easily found location or manner. Except when the error, warning or notice causes pacman/pamac to fail. Even then, I wonder how many newbs, using the pamac gui, get frustrated when an install “silently” fails because they don’t know where to look for the log in the gui.
While many people will never, ever look at the PDF manual that ships with new Manjaro installs, it does a reasonably good job of familiarizing those who do look with some basics of using and administering their system. Some mention of .pac* files should be in there.
Thanks for the feedback. @guinux Maybe you could add something to the GUI regarding .pacnew / .pacsave files?
1 Like
Dealing with pacnew files is very technical point and propose to edit/merge them won’t really help an user who doesn’t know what is the file purpose.
My opinion is that it’s a lack of libalpm to just give the opportunity to inform the user about a pacnew.
Anyway, in Manjaro, a critical change should be handle automatically by an update of manjaro-system package.
3 Likes
Possibly, but some changes cannot be automatically merged if it’s a file that can and will be changed by the user like /etc/default/grub.
1 Like
What would you propose?
1 Like
I think a warning if there is output on command /usr/bin/pacdiff --output would be a good start at least to let the user know there is something to maybe look at.
2 Likes
On pamac and pacdiff, I have been using exclusively pamac for updates and upgrades.
Question: does pacman have the same “problem” with failure to inform the sysadmin about the pacdiff, if any? (I assume it does.) Should a proposal to collect warnings and so on and present them to the sysadmin be pushed to upstream Arch?
On another note, I have never worked with an operating system that collects and reports package errors and warnings in a findable and useful manner. It is something I have silently complained about for almost 20 years. FreeBSD, Debian, Gentoo, Red Hat, SourceMage, etc. Even Windows and MacOS fail in this regard. I can’t help but think it would reduce the headache of sorting out what went wrong after a system upgrade and quickly rollback affected software to a known-stable state before doing deeper investigation on a different system (yeah, yeah; best practice is always to keep a test system around. Not every has that luxury). Didn’t AmigaOS do this in 1980s? If yes, why did it never catch on?
===
Also, RSS told me about an hour ago that there’s a new Stable for me to update to and check for what has become normal post-update breaking of my user-settings. I don’t plan to update until some time next week, preferring to wait for any additional bugs and misfeatures to be attended to. I’ll post my experience here again. Given that kernels and KDE-plasma are on the menu, I expect my user-modified display environment settings to get mangled again.
I would really like to learn of a useful way to automagically scan for and report when my user-settings are changed by updates. I don’t think such a thing exists.
User settings, in the user home, are NOT changed by updates.
So you say, but my experience does not match your statement, else this topic would not be here.
Update:
I did the latest stable update today.
For the first time in more than 6 months, none of my user settings were changed on updating. At least, none that I have yet found.
Previously, my KDE panel arrangements were completely mangled, which was always the most obvious user-settings that got changed on updates. Other user-settings were also affected.
I’m happy to report that today’s update does not appear to have changed any of my user settings. Yay!