Am Tue, 15 Nov 2011 23:50:35 +0100 schrieb Kevin Kofler <[email protected]>:
> Thomas Lübking wrote: > > And that is gonna happen in what way if it's not in any lib? > > Static linking?! External lib? Problem solved? > > Applications which are not part of KDE SC might end up just requiring > a patched kdelibs to even build. I am sorry? If I write an application and try to rely on a feature that is not existing in _any_ lib I link to, I'll have to implement that feature myself (where "implement" can be as dumb as cnp) The danger that (3rd party) application might start to operate on forks of kdelibs is *exactly* what I started to fear when that "let's coordinate downstream patches" talk started. (No offense Scott, I still do see the temptation ;-) The possible results would be a) you can't build against the "vanilla" kdelibs b) regressions in case those fork additions do not get into frameworks (for whatever reason, i'm not talking about the pending ones) - unless the application copies it over. Therefore my suggestion (if opening 4.x even as wrapper linking frameworks is no option) would be to compile the features into the application requiring it right now rather than forking a *library* because you cannot alter it. (Don't forget: this is about covering the time to frameworks, thus temp. bloat can be accepted to a certain degree for a better good) A short term fork (you patch your stuff into fedora17 etc) will likely not harm, but in the mid term there needs to be a re-coordination between up- and downstream to allow a as seamless as possible transition from kdelibs to frameworks in the long term. Cheers, Thomas
