On Friday, February 19, 2021 2:24:26 PM CST DennisG wrote: Just a few more notes and then some short replies to some of your points. Akonadi has become quiet. Kontact still shows its "Unified Mailboxes" thingy at 0%, but it also says "Ready". I don't know what that's about. Also, wouldn't akonadi be more serviceable if some portion of it ran at a lower priority by default? My temp sensor has an updated version that doesn't crash plasmashell. Still, that strikes me as a plasmashell vulnerability that it can be brought down by some random app. Ksysguard's process table insists insists on showing itself at 30-40%, while its CPU History shown a quiet system at 10% (for each of two CPU's). And on to a few comments...
I've read the other replies, some good advice there. Fwiw (or not), since you asked . . .
I've been using the DVD upgrade method for ~20 years. I (still) find it the easiest, and agree with the openSUSE documentation that states this is the most "robust" method. While most on this list are probably fans of using zypper and that is just fine (I'd also guess most are also intermediate-to-advanced users), IME the DVD is easier/better for resolving hiccups before the user commits to the upgrade. But with either route the user has to understand his/her system and the process very well, if surprises are to be avoided or mitigated.
And that's the method I've used for many years with prepackaged systems like 15.2. I just had an aborted attempt at adventurousness before settling down this time, with a couple of exceptions. I left two repositories in a disabled state (with updated url's) rather than removed. One was the munix9 one from which I drew celestia. Could that be the reason celestia wasn't deleted and was ready to be upgraded once munix 9 was reenabled? and the other was opensuse-guide, which might be what redirected me to videolan under the same circumstances. That said, I did maintain a Tumbleweed installation for a couple of years using zypper up and lots of package cleaning using Yast. I still have that installation.
Consequently one practice I borrowed from my enterprise days has been to /always/ perform a proforma upgrade. I keep storage on each machine to which I can copy my production system, test the upgrade process and then exercise the post-upgrade system with a representative suite of tests. The most difficult problems I recall have invariably been with graphics or new hardware. Or with KDE - which I blame on myself for stubbornly continue to use it. :)
That's actually sort of difficult for a home user with one cheap, old computer.
IMO it's also very important to clean up one's repositories and current software setup beforehand. Having many hundreds of files to delete or a load more not making any sense, would move me to look closely first to understand what this means.
See above, in re Tumbleweed. ;-) Also, I think I know the source of some of those few orphans. One would be pacman with multiple libraries where earlier ones are quietly abandoned. Another would be Application:Geo, which I've used heavily in the past. I haven't looked yet, though.
I'm only using ~150 Packman files, mostly multimedia apps with half the files being the libraries. Maybe you use a lot more from Packman than I do, but I would l want to understand the "whatnot" that you had "not looked further at" before. I do include Packman in my upgrade by switching the repo beforehand and then during the upgrade toggling YaST to include it. Going to 15.2 I got maybe 50 conflicts but nearly all were about version differences for which I just needed to decide which to use; all but a few were recognizable and dispositioned quickly. There are always a few where the dependencies need to be realigned. The ability to load the YaST Software module and work thru these with all its power, ensures that at least the software stack is clean before committing to proceed.
Same same, mostly.
Each cycle I regularly accumulate about a dozen additional OBS repositories for this or that app or to get a newer version, but all of those I remove and let the upgrade revert the files to the new main repo versions (which typically are as new/newer than the version I had added before). IMO trying to include all these in the upgrade would mean I must have a pain fetish.
This is sounding very familiar, though I may not be as careful as you.
No comment on your xfce vs kde issue, except to say I probably wouldn't mix the two and if I did, frankly I would not consider that an openSUSE glitch unless it is a supported function/feature.
Hey, the login screen gives a choice of desktops. [...] Now, to Netflix, then bed.