On Tuesday, February 1, 2011, Maksim Orlovich wrote: > On 2/1/11, Andreas Pakulat <ap...@gmx.de> wrote: > > On 01.02.11 19:49:10, Albert Astals Cid wrote: > > > > No, the natural fix is to make the dependency chain proper, i.e. KTE > > depends on kdelibs, khtml depends on KTE+kdelibs. That means khtml > > cannot be part of kdelibs anymore if KTE is not part of kdelibs anymore. > > Funny, I would think the proper fix would be for people who put their > work into kdelibs to honor the requisite commitment to backwards > compatibility, rather than to punish other > libraries for doing the right thing in using existing facilities.
it's not about punishing any library or individuals' work. if we modularize kdelibs, then that means we may end up with a small set of interconnected repositories with clear dependency chains. for instance... we could end up with a "new kdelibs" module that contains just the core stuff such as kdecore, kdeui, kio .. there could be requirements in there about allowable dependencies between those libraries. we may even decide to split things up into "dev framework" vs "platform target". (if this sounds like "KDE5" sort of stuff .. well .. yes :) then we'd have other pieces that have been put into kdelibs in the past that maybe should live on as part of the KDE Platform (or whatever call it) but in their own repositories. that could include the KTextEditor interface, perhaps libplasma as well. so in the case of something that uses KTextEditor and is part of kdelibs now, it could still be part of the KDE Platform but be its own module with a dep on corelibs+kate. which is really no different than it is right now, except everything would be explicit and not in one single repository. the big change here would be that applications that require different parts of the KDE Platform might have to define which parts to include (e.g. KTextEditor interface) rather than them being provided implicitly in one big chunk as it is now. the domino effect there would be altering CMakeLists.txt for apps that need KTextEditor (for example) to explicitly include it. alternatively, we could maintain a compatibility FindKDE4-style macro that would pull in all those pieces. so apps that did nothing would still have the same build profile without any modifications, just risk pulling in more libraries than they really need as build requirements. a "virtual" kdelibs if you will. we sort of have this already with kde-support, imho. apps could then be updated as desired to more accurately note their needs, bringing dependency definition into sharper definition. but most importantly, new apps, or existing Qt apps, could then much more easily say "I just want libkdecore" or "I just want libsolid" and get it. there are a hell of a lot of details in between all those broad strokes. if we start pondering them now, though, by the time we hit Randa in June we may be in a very good position to have effective discussions that result in actual decisions :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
