Which package will provide the common KDE library version number ?

[Alexander Neundorf]

On Saturday 10 March 2012, David Faure wrote:
> On Monday 27 February 2012 17:48:44 Alexander Neundorf wrote:
> > A common setup will be that "core" developers are building all frameworks
> > libraries.
> > Let's say some tier1 library, e.g. kcore needs Qt 5.1.2 and cmake 2.8.9.
> > Another tier1 library, let's say solid, maybe says it needs Qt 5.1.0 and
> > cmake  2.8.8.
> > 
> > But since due to kcore already Qt 5.1.2 and cmake 2.8.9 are installed and
> > available, it may, no, it will happen that solid accidentially uses
> > features  from Qt 5.1.2 and/or cmake 2.8.9. The developer will not even
> > notice that the required versions of Qt and cmake (5.1.0 and 2.8.8) are
> > wrong.
> > So other developers will try to build solid and it will fail at
> > buildtime.
> 
> Accidentally using "too new" features (from cmake, Qt, or any other
> dependency) already happens frequently with different KDE modules. Or even
> within the same module, one developer uses a "too new" feature, which
> breaks compilation for other developers on the same module.
> So this is not an argument for this discussion, it's unrelated and mostly
> unavoidable.

Continuous/nightly builds using the official minimum required versions would 
help.

> > Do we really want that any of the let's say 20 libraries can require a
> > newer version Qt and so enforce a rebuild for everybody ? or cmake ?
> 
> This, on the other hand, refers to *documented* (not accidental)
> differences in requirements. Note that we already have exactly this in KDE
> too. When I ported konversation to new-in-kdelibs-4.5 API (at a time where
> 4.6 was already out), it broke compilation for people compiling
> konversation on top of kdelibs-4.4, which was apparently still a supported
> target for konversation. It makes things difficult for people like me (who
> like to touch everything in KDE), but on the whole it's not so crazy that
> different modules have different requirements on their dependencies.

To summarize: do you say it is ok to let every KDE frameworks git repository 
decide for its own which versions of Qt and CMake it requires ?

For me, this would be the least work (implementation wise): we'll have a fully 
independent set of libraries with maintainers, who all take care that 
everything is working fine, and using those independent libraries together 
makes sense.

This gets us AFAICT to the same dependency situation as gnome has.

Also, this means the term "KDE frameworks" doesn't actually mean a lot.
I mean, what would make a library a "KDE frameworks library" ? 
Being part of the KDE SC releases ?

But I'm really not sure this will result in a pleasant experience for 
developers and maybe also packagers to build the whole thing.

If we go that route, I'd like to have somebody volunteering to do the support 
for all those people who will have problems building due to dependency 
problems, or a strange mixture of versions that has been found, or people 
complaining that they already have to upgrade their cmake again because some 
library upped their required version. I don't feel like doing the support for 
this.

If we want to keep a mostly smooth experience for developers working on 
multiple parts/the whole KDE SC (which is IMO one of the things which make up 
"KDE"), this is IMO not the way to go.

Alex