Which package will provide the common KDE library version number ?

[David Faure]

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.

> 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.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5