This starts to become a dangerous path (Was: New Feature for kdelibs)

[Thomas Lübking]

Am Tue, 15 Nov 2011 23:50:35 +0100
schrieb Kevin Kofler <kevin.kofler at chello.at>:

> 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