Which package will provide the common KDE library version number ?

[Ben Cooksley]

On Sun, Mar 11, 2012 at 12:18 AM, Alexander Neundorf <neundorf at kde.org> wrote:
> 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.

We have Continuous builds of some projects already - see http://build.kde.org/

>
>> > 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
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Regards,
Ben