downgrade to KDEP5?

[Duncan]

David Chmelik posted on Mon, 11 Mar 2024 06:13:16 -0000 (UTC)

Imagine meeting you here! =:^)  (We're both active on the pan newsclient 
list, as in the user-agent header, as well.)

... as excerpted:

> We tried KDE Neon 6 (and had problems mentioned on discuss.kde.org
> threads like 'are you out of your mind to release such a faulty update'
> and 100+ other major problem threads since) which broke 2/3 our PCs (one
> inoperable) so downgraded to OS with KDEP5.

AFAIK kde/plasma 6 isn't really considered stable yet -- it's just the 
first full release to get it out there for broader testing by those 
willing to deal with the problems in ordered to be running the newest 
release.

Of course I'm testing actually live-git (via the gentoo/kde overlay live-
git package-ebuilds), not even released-versions but the goal is CI/CD 
stability level and deployed here, they do seem to meet that goal most of 
the time, for people like me prepared to deal with the occasion fallout 
when something goes wrong.

I guess that would correspond to Neon Testing?

But even the most stable of the Neon editions, the User edition, is 
recommended for "adventurous users" (Neon FAQ, What is KDE neon?), "who 
want to experience the latest and greatest software as quickly as 
possible", with the caveat that "using the latest software the moment it's 
released will inevitably result in a less stable experience compared to 
distros that delay software by days, weeks, or months.  As such the ideal 
KDE neon user is someone excited to use the latest and greatest KDE 
software who can tolerate some bumps in the road from time to time, not 
someone with mission-critical reliability needs." (FAQ, Who is KDE neon 
for?)

So presumably you're not using it for mission-critical and are willing to 
tolerate those "bumps in the road", as the faq says...

And because it's related, back a few years ago I was hanging out on the 
btrfs lists while it was still unstable enough to have a big warning 
attached to the kernel config option that enabled that filesystem... and a 
lot of folks came in there after-the-fact of defining their data as not 
worth a whole lot by their action of running a still unstable filesystem 
and not having backups of the data they were placing on it...

Because the value of the data in question is defined not by mere claims 
but by the number of backups considered worth the trouble to keep, just in 
case the working copy AND the N-1 level of backups ALL fail at the same 
time... and especially because in this case the running software is known 
to be not suitable for mission-critical reliability so the calculated risk 
factor is accordingly higher than normal... those backups either exist and 
can be restored from should the need arise, or by definition the value of 
that data has been established as below that of the time/hassle of doing 
further backups.

(IIRC back on that then still unstable btrfs list, one unlucky poster had 
even defined his /wedding/ pictures as of low enough value not to have 
even a single backup... while storing them on that then still unstable 
filesystem!!!  One can only hope that whatever photography services he 
used for that wedding still had rather higher value definitions for that 
data... and of course that they charged in accordance with that defined 
value as part of the value proposition of their services.)

> Now that ~/.kde doesn’t seem
> much-used, what do I delete from ~/.config & ~/.local/share so KDEP5 is
> usable again (downgrade led to many bugs/crashes)? I know most stuff
> starts with k, but a lot also doesn’t: maybe Okular and a large amount
> of optional KDE software we have but I can’t keep track of.

Ideally you can just restore from backups made before the upgrade and not 
have to worry about sorting through the changed config.  But it reads like 
you lost the backups bet and the costs must now be paid...

Which I do at times too, yes, even running live-git versions! After all 
it's a calculated but at the time as yet untriggered risk against a known 
time and hassle value!  =:^]

What I do when I lose the bet in those cases is make an after-the-fact 
backup, wipe the directories in question, and restore on either a bisected 
or case-by-case basis.  (Bisected in this context means split in half, 
restore the one half and see what works or is still broken, split either 
the restored half or the unrestored half in half again so now in quarters, 
and repeat, then repeat with eighths, etc, until either the bad is all 
sorted out or the remainder is small enough that the hassle of 
reconfiguring it is less then the hassle of continuing the bisect.)

For me at least, that works /reasonably/ well (given the circumstances 
I've found myself in), because kde's my only desktop (tho I do have the 
minimal weston compositor as a backup wayland compositor), so most of the 
stuff under ~/.config and ~/.local/share is either specifically 
identifiable and thus excludable from my bisect (either don't wipe it at 
all or restore it unconditionally), or if not easily/specifically 
identifiable, can be assumed to be kde-related.

If I were running gnome or something else big enough to have a whole bunch 
of non-specifically-identifiable stuff in the standard XDG locations, as 
well as kde/plasma, and was significantly worried about losing the config 
and some data of both/all of them... well, I guess I'd then need to define 
the value of that data to be higher because the cost of sorting its 
corruption/loss would be higher, so I'd hope I'd keep better backups to do 
so!  =:^]

Well either that or I'd be aiming for something a bit more stable than the 
live-git stuff I run...  Or maybe both more stable and more backup 
updates!

> We’ll try KDEP6 when FreeBSD UNIX, Slackware & Kubuntu LTS GNU/Linuxes
> upgrade.

That reads like it might be a policy better matching your instability 
tolerance, agreed.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman