proposal: remove KTextEditor interface from kdelibs repository

[Sune Vuorela]

On 2011-02-01, Aaron J. Seigo <aseigo at kde.org> wrote:
> --nextPart3865859.bpjpIik9D5
> Content-Type: Text/Plain;
>   charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> On Monday, January 31, 2011, Michael Pyne wrote:
>> On Monday, January 31, 2011 17:42:56 Aaron J. Seigo wrote:
>> > potential caveats are that it makes it harder to build certain KDE apps
>> > because now you need not only kdelibs, but kate. this is already true f=
> or
>> > things that require libs in kde-support, kdepimlibs or kdegraphics,
>> > though.
>>=20
>> This is more a package management concern, and while I do want to avoid
>
> indeed; i'm hoping one or more of the packagers will chime in at some point.

I have commented on the kate developers plans more than once, but people
just seems to bring it up over and over again. But no. Nothing has
changed in my perception of things.

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.

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)

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.

I'm unsure why we wants to break the promises we made to the rest of the
world about the stability of our libraries.

(oh. and why should a kile/kdevelop/... user compile and install kate?)

/Sune
 - who as a packager will have a hard time effectively undoing this work
   in order to *keep* the compatibility. As a packager, I actually trust
   KDE to live up to their promises.