Yet another failed KDE release?

Kevin Krammer krammer at
Wed Mar 27 20:54:28 GMT 2013

On Monday, 2013-03-25, Duncan wrote:
> Kevin Krammer posted on Sun, 24 Mar 2013 16:41:35 +0100 as excerpted:

> And in fact that was what I guess kubuntu and some others were (rightly,
> it turned out) predicting, the reason they didn't do an LTS at the time,
> because they didn't believe the upstream support would actually be there.

This was mostly a result of Canonical not actually doing any LTS work on 
anything other than their main product. 
Doing another Kubuntu LTS could have meant spending actual resources on 
maintenance and that is not something they were comfortable with.
Naturally all actual LTS level distributors (SUSE, Red Hat, Debian) continued 
to do what their users and customers expected them to do and as usual shared 
the maintenance efforts between them.

> > I think the main problem here is lumping together different highly
> > independent products into one term.
> Thanks for continuing to emphasize that, Kevin.  It's certainly going to
> be interesting to see how the kde frameworks 5 thing plays out,
> especially given that qt5 is going the much more modular route at exactly
> the same time, with most components of each becoming optional, only
> installed when a specific app needs them.

Qt4 was already very modular, Qt5 mostly just changed which libraries are 
considered essential and which are not.
A lot of modularity is discarded at packaging level, e.g. if a package is just 
libqt4 then an application package which would only needslibQtCore4 would 
still depend on all the other libraries.

While Qt is fortunately mostly packages in a split way, KDE's libraries have 
traditionally not been. The Frameworks 5 efforts are a lot about making that 
more obvious, hopefully leading to a situation where there are separate 
packages for separate libraries.

> But there were a few feature drops as well.  The biggest two projects I
> can name here aren't part of kde-core, but they're headline kde apps and
> thus very important: kaffeine, and amarok.
> AFAIK kaffeine for kde4 simply took too long to mature, and in the mean
> time, it simply didn't have the power features that people used it for in
> the kde3 era, instead of the many other media player alternatives out
> there.  Features like frame-by-frame advance and incremental playback
> speed.  These are advanced features that simply aren't available in the
> default level offerings, kde3 OR kde4, that had people using kaffeine for
> kde3 instead of the lower featured alternatives in the first place.

Ah, didn't know about the change in Kaffein, never used it myself, I am an 
mplayer (console) user :)

> Which leaves amarok.  Amarok's kde3 -> kde4 conversion was for me a
> microcosm of the larger kde3 -> kde4 debacle.  The devs tried switching
> to mysql as akonadi was at the time, but in the process, they used mysql
> functionality (something about a mysql library for use in other apps,
> I've forgotten the details) that was completely broken on amd64/x86_64 at
> the time, because as all libraries on amd64, the library in question
> needed built with -fpic, but as that library was a part of the larger
> mysql package and building the rest of it with -fpic would have meant
> unacceptable slowdowns for the executables, nobody was actually building
> it with -fpic.

This is strange, could that be a Gentoo artifact?
MySQL is officially supporting in-process for some of its backends (usually 
MyISAM) and as far as I can tell worked well for most people I know (but those 
are all Debian users).

It can be hard to tell from a developer perspective if something that is 
officially supported by an upstream dependency does not work under some 
circumstances and that some of your downstreams are triggern those.

Btw, isn't there a continuation of the Amarok version 1 project? I think it is 
called Clementine or something like that.

> I do sort of wish gwenview would implement audio file support, however,
> and thus be a full media filemanager.  Media files are my biggest use
> case for user-side/full-GUI file management, and gwenview handles images
> and video well enough that I use it almost exclusively for them, but it
> totally hides everything else, including audio-only files, which are now
> one of only two things I use dolphin for.  The other is as a trivial-case
> file browser, basically a file open dialog on steroids.

Interesting idea, have you checked if there is a wish item report for that?

Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <>
-------------- next part --------------
This message is from the kde mailing list.
Account management:
More info:

More information about the kde mailing list