ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+

[Kevin Kofler]

On Saturday 09 June 2012, Albert Astals Cid wrote:
> There is not stupid not weird thing in kdelibs. We simply declared kdelibs
> to be feature perfect and only bugfixes should be happening there.
> 
> What's the problem with that?

That no software is ever perfect.

For example, we will NEED the Solid udisks2 backend in future releases of
Fedora because udisks 1 is going away! As far as I know (I'm not a Red Hat
employee), it will be used in the next release of RHEL as well. So we have to
backport it as a distro patch. (The author of the backend did the backport.)
For the other distros:
http://pkgs.fedoraproject.org/gitweb/?p=kdelibs.git;a=blob;f=kdelibs-udisks2_prep.patch;h=2962837cdbc3cc1200ce323902f9173b79c2b1b5;hb=HEAD
http://pkgs.fedoraproject.org/gitweb/?p=kdelibs.git;a=blob;f=kdelibs-udisks2-backend.patch;h=74ec3c2872d118d0335cc95c608a95ef9cd40f92;hb=HEAD
http://pkgs.fedoraproject.org/gitweb/?p=kdelibs.git;a=blob;f=kdelibs-udisks2_post.patch;h=f22742dc8db8b2dd2b48de6f916c4a50a360db6b;hb=HEAD

kdelibs has now been feature-frozen for a year, and it looks like it will live
at least 2 years in feature-frozen state, plus several more as a compatibility
library. (We still ship a kdelibs3 compatibility library in Fedora, it's still
needed, e.g. for Quanta.) This is just unacceptable.

The libraries should be the LAST thing to be frozen, even after the core
applications have already moved on, because of the many third-party
applications relying on them. Freezing the libraries first, when even the core
applications still rely on the "old" version, just makes no sense whatsoever.

        Kevin Kofler