This is no technical reason why this isn't possible. The only limitation is manpower - every package which depends on kdelibs would have to be analyzed to figure out which libraries it actually uses. However, the change doesn't have to be made all at once - the existing kdelibs package can be replaced by a metapackage during the transitional period. Debian is already doing this. See http://packages.debian.org/sid/kdelibs5. Their package database could probably serve as a good source of dependency information. This would be extremely valuable for those who don't actually use KDE, but occasionally need a program or two which require kdelibs. Reproducible: Always
This is something that has been raised before by some KDE developers, but there was no progress made yet. I can't talk for the other KDE herd members, but until KDE splits the tarball, I wouldn't even think about going forward with this. Also, KDE (upstream) already complains about our choice to "minimize" dependencies as frankly most developers seem to think that users should be "forced" to install kde-meta.
From the point of view of user, I always give KDE under Gentoo as an example of package modularity chosen just right. Not too fine grained, not too monolotic
Definitely we're no going to split it unless it's actually split at build system level upstream. Besides there's little point. The only 'splitting-worthy' parts of kdelibs are: - khtml/ (+kjs maybe and kjsembed) - kdewebkit/ - plasma/ - nepomuk/ - solid/ Nepomuk is already optional by the means of semantic-desktop USE flag.
With me as the third (albeit junior) team member thinking that this makes no sense at the moment, I'm resolving this as CANTFIX.
