On Fri, Mar 22, 2013 at 11:29 PM, Duncan <1i5t5.duncan@xxxxxxx> wrote:
Major releases, (1.x, 2.x, 3.x, 4.x), use different config directories.
I remember reporting a phonon bug a year ago related to the config and deprecated xine backend; but the devs ignored it possibly cause they were rushing through releases, and creating a new tags every 10 days.
Kevin Krammer posted on Fri, 22 Mar 2013 12:53:01 +0100 as excerpted:
FWIW, that's true here as well. I've been running the same kde config,
>> Honestly, why can't KDE SC support seamless update from previous major
>> release? Is it too much work to rewrite config files whose format has
>> changed?
>
> This is of course intended to happen, KDE software has had configuration
> and data modification tools for ages. My personal setup has been with me
> for over a decade now, rarely prompting me to reconfigure things.
with /home copied over to new hardware (which on my workstation unlike my
netbook, I upgrade a piece at a time so there's never a new computer,
just a changed out drive, or max-change, a changed out cpu/mobo/memory/gpu
all at the same time, as all the buses and formats had changed so to
upgrade one I had to upgrade them all, but then it's the old hard drive
installed in the new machine) as appropriate, since kde 2.x in late 2001,
when I switched from MS to Linux.
Yes, that's the same base kde2 config now running kde4. Every once in
awhile, especially after the 2.x to 3.x upgrade and later the 3.x to 4.x
upgrade, a few months after the upgrade I go thru and check file times,
moving files to a backup location if the mtimes haven't bumped since the
update, to see if they get recreated and/or whether they're I lose any
customizations.
Major releases, (1.x, 2.x, 3.x, 4.x), use different config directories.
And yes, there's specific files (the infamous plasma-desktop-appletsrc
being one of them) that I keep extra backups of and usually backup before
any major changes, as I've learned the hard way how difficult it can be
to find and edit out the bad bits on the more complex files if something
does go wrong.
And yes, when I hit a problem, I know how to use the bisect method to
narrow it down to a single config file if I have to (tho after doing it a
few times and figuring out the way kde organizes its config, I found I
could often pick the problem file purely by name, or at minimum, reduce
it to a handful of files right away, so the bisect is now often only 3ish
rounds max), and am used to doing just that, in kde config files or using
git to bisect a kernel bug, either way.
I remember reporting a phonon bug a year ago related to the config and deprecated xine backend; but the devs ignored it possibly cause they were rushing through releases, and creating a new tags every 10 days.
But it really is possible to use the same basic config that long, even
with heavy customizing, and I'm a case in point.
My problem isn't so much with that, it's with killing support for old
versions before the new versions are sufficiently stable replacements,
ESPECIALLY after promising support "as long as there are users!" That
triggered a drop of a lot of my former kde software choices with the bump
to kde4, when kde was insisting that kde4 was stable and that they
weren't supporting kde3 any longer, at the very SAME time they were
saying on bugs "Oh, that's not ported to kde4 yet." The story repeated
with the akonadification of kdepim; I honestly DID try the akonadified
kmail, but somewhere about the time it lost my 10th mail or so and I was
trying to figure out whether it got caught in akonadi somewhere or was
simply gone (after having to do much of the conversion manually in the
first place because the automated process failed), I asked myself why I
put up with it, why I couldn't just expect, AND HAVE, email that "just
worked", that devs didn't needlessly change something that was working
perfectly fine as it was, breaking it in the process. (Ironically, I
ended up on claws-mail, one of the "short list" of clients I had
evaluated but eventually dropped for kmail, back when I originally
switched from MS and OE. It's still using the same mh-dir mail format it
was back in 2001... and it still works. Only unlike kmail, they didn't
drop a well working solution in a chase for utopia. Had I only chosen it
back then...)
But, as I said earlier in the thread, that means I'm now running only the
core kde desktop, with nearly all of my "mission critical" apps now non-
kde and to the extent possible, with semantic-desktop not just disabled
at run-time, but without support for it even built at all. Which means I
don't have to worry about a broken kde killing my mail (for instance) any
more. Which means I'm now much freeer to run and /enjoy/ running the kde
pre-releases. =:^)
And it also means if kde pulls the kde4 stunt again, since it's only the
core kde desktop and a few games I'm running now, it'll be MUCH easier to
drop it entirely, if I have to.
Fortunately, kde5 aka kde frameworks is supposed to be a much less
disruptive upgrade, and it's going much more modular as well, so it's
much less likely. But THIS time I'm prepared, should it happen. I won't
be caught not viably being able to switch, again.
Which is even more proof that kde's not going to drop the ball that way
again, because I'm actually prepared for it now, so of course it's not
going to happen. =;^]
Of course there's the possible upcoming xorg -> wayland switch to worry
about too. That could really upset the Linux desktop environment status
quo in all sorts of interesting ways and I think most of the leading DEs
realize that. But again, I'm much better prepared now, so regardless of
how it turns out or what DE and apps I end up running on wayland and what
kind of promises DEs and their devs make that they ultimately end up
dropping like yesterday's dead fish in a malfunctioning refrigerator, I
expect that switch to be far less personally disruptive than the kde3 ->
kde4 upgrade was. Which means to a certain extent I'll be able to sit
back and enjoy the ride instead of sweating it out so badly this time,
and I really am looking forward to that. =:^)
--
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
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
___________________________________________________ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
