proposal: remove KTextEditor interface from kdelibs repository

[Kevin Krammer]

On Tuesday, 2011-02-01, Christoph Cullmann wrote:
> On Tuesday, February 01, 2011 11:11:08 am Sune Vuorela wrote:

> > So far, we as packagers have been told that applications can expect all
> > plugins (kio slaves, kparts, ...) located in kdelibs and kdebase-runtime
> > to be available, and segfault is a acceptable way of handling missing
> > things.
> 
> I agree that this will lead to additional dependency to kate package for
> some modules, but is this that bad?

It would require a new kdelibs package (the new one will no longer satisfy the 
same needs) or require that the packagers extract the interface related things 
from kate and add them as a dependency for the kdelibs meta package.

> > Application developers has made their *current* apps based on this, and
> > stuff will break by moving e.g. katepart out of kdelibs.
> > 
> > Now KTextEditor. KTextEditor is a public library in kdelibs. This means
> > that people can actually expect KTextEditor to be there when they do
> > 
> > find_package(KDE4 REQUIRED)
> 
> Yeah, and because of this requirement, which I can agree on, I didn't
> remove it from kdelibs, as its public API and I wanted to be SC + BC. And
> no, runtime components moving to other modules is not a SC/BC problem.

While it is SC/BC, it changes the contents of the kdelibs package.
Either packagers put in extra effort of extracting the now missing parts from 
Kate and add them as dependencies to kdelibs or they create a new version of 
kdelibs which no longer satisfies the dependency rules of all applications 
packaged against the old one (or with even more effort adding the old kdelibs 
package as an alternative for all program packages that do not use the runtime 
dependency).

> > It also means that people who builds from source can do svn up / git
> > pull  in kdelibs and install new requirements,make, make install and
> > still have all apps working.
> 
> They never can do that. Every now and then new dependencies come up. New
> versions of virtuoso needed, new lib*, whatever. You NEVER was able to rely
> that you can just up + recompile kdelibs and be fine. Normally it not even
> compiled...

The difference is that new dependencies add things to kdelibs so they can only 
be used by applications built against that new version. Removing a dependency 
would mean you'd have to check all applications on whether they need the 
removed dependency and explicitly add it to their dependency list.

Or do you mean kate would become an additional depencency of kdelibs (however 
that would work)?

> I still no get this problem. kdelibs adds more and more dependencies over
> the last years, same for other modules. Why is this dependency change
> different at all? It is not even a compile time dependency change...

My guess is that there are different rules for removal of functionality than 
there are for adding.
On source or binary level we can always add (non-virtual) functions but we 
cannot remove any.

When we make kdelibs depend on something, we usually put quite some effort 
into our layer to make sure we can change dependencies without changing 
dependencies for apps built on kdelibs, e.g. make kdelibs depend on different 
libraries for new Solid backend implementations without requiring new 
dependency rules for all applications using Solid.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110201/1355d5b9/attachment.sig>