Packages split from kdebindings don't need to be tied to the same kdelibs as their version. For example, kde-base/smoke only needs kdelibs 3.1 or greater (meaning that the build that depend on it need the same as well). KM_DEPRANGE only accepts a minver in the same minor version number. So, we'll either need to modify kde-functions.eclass to take it into account, perhaps consider making KDEBINDINGS a non KDEBASE setup, or do some manual hand tweaks to the split ebuilds. Thoughts? Reproducible: Always Steps to Reproduce:
Hey Dan, what are you thoughts on this?
It's easy enough to add a flag for using kde-meta.eclass without the split-ebuild-style deps. The question is what deps we want precisely. Is there uptodate documentation on what kdelibs versions each bindings package needs?
Old bug, no one cared a while... I for one think it is not friendly to let our users allow to mix packages of different KDE versions, let them file bugs upstream and see kde.org devs getting grey hairs. ;) In half a year there's only KDE 3.5 left anyways, so I hope you're fine with it, that I resolve as won't, Caleb.
