Which package will provide the common KDE library version number ?

Wed Feb 22 20:52:24 UTC 2012

On Wednesday 22 February 2012, Kevin Ottens wrote:
> Hello,
> 
> On Sunday 19 February 2012 20:10:05 Stephen Kelly wrote:
> > Alexander Neundorf wrote:
> > > Can KDE frameworks libraries of different versions be mixed together ?
> > 
> > I would say that's unsupported (by us). The ones that work together are
> > released together.
> > 
> > We're not going to test all possible (and numerous) version combinations.
> > We don't need to make it impossible, but we don't need to ensure that it
> > always works either.
> > 
> > If someone else decides that they want some random version combination to
> > work (for a reason I can't think of), they can maintain that combination.
> 
> +1

Does maintain mean "check out the different versions from git and compile them 
together" ? This would be no problem at all with my proposal below.

Or does it mean using a mix of different libraries, some self-compiled, some 
from the distro ? This would be possible, but a special case which would need 
some manual tuning.

> > > E.g. can I build a tier2 library against different versions of tier1
> > > libraries, or does this in general only work if they have the same
> > > version ? If so, they wouldn't necessarily share the same KDE
> > > frameworks version number...
> > > 
> > > 
> > > Can I install different libraries from the KDE frameworks set of
> > > libraries to different locations and use them together ?
> > 
> > I don't see why not. As long as CMAKE_PREFIX_PATH has the correct
> > content.
> 
> +1

See below for version hell.

> > > If the answer to these questions is yes, then KDE frameworks is really
> > > just a set of loosely coupled libraries, which of course can have
> > > different versions.
> > 
> > Yes, but the KDE applications and workspaces will use one version of all
> > the frameworks that they use.
> 
> Exactly. I'll stress it again though: with KDE Frameworks, KDE Applications
> are one of the possible downstreams, we want to have others which have more
> a profile of "Qt + a couple extras".

That's ok, and I don't see how my proposal below would be a problem for that.

> > > If the answer is no, i.e. if these libraries should still be seen as
> > > one coherent package,
> > 
> > I would say that from the perspective of a developer creating a KDE
> > application, it is one coherent package.
> > 
> > From the perspective of a Qt application developer who wants (for
> > example) to be able to create zip files (using karchive) or some extra
> > itemmodels classes, the libraries are distinct.
> 
> +1

It depends on what we want.
If KDE frameworks will simply be a set of libraries which make sense when used 
together, and which have dependencies among each other, but not any stronger 
coupling, then +1  (i.e. we'll have the same dependency issues as gtk/Gnome).

If we want some more integration, e.g. to avoid version hell, then -1 .
The feedback from the last 6 years including the last few weeks tells me we 
want the more integrated version:
David: http://lists.kde.org/?l=kde-buildsystem&m=132964195530472&w=2
Christophe: http://lists.kde.org/?l=kde-buildsystem&m=132982351214275&w=2

I interpret both so that they both say they want to rely on the fact that a 
git pull from different libraries of KDE frameworks at the same time will give 
a working combination (yes, in different git repositories there is no defined 
same time anymore as we have a revision number in svn).

> > > then there should be a package they all depend on,
> > 
> > I don't follow the logic from 'they can be seen as one package' to 'they
> > must share a common dependency'.
> 
> Me neither, and I don't think it got addressed. Alex could you clarify on
> that? It could perhaps help me in understanding why you want that common
> dependency so badly in that case (I really mean the version numbering here,
> the common dependencies like ECM and Qt are probably a very different
> story).

It's the common version number, it's the common install directory setup, it's 
the required versions of common dependencies (QtCore, cmake, extra-cmake-
modules), maybe more I am currently not aware of.

Install dirs:
------------
We have a set of directories where we install different types of files to.
E.g. for plugins to be found, they should be installed somewhere under 
PLUGIN_INSTALL_DIR. desktop-files should all go into the same directory.

Now let's say somebody currently does something like the following for 
kdelibs:

cmake -DPLUGIN_INSTALL_DIR=/usr/lib32/kde/plugins 
    -DXDG_APPS_INSTALL_DIR=/usr/share/apps/ -DLIB_SUFFIX=32
    -DCMAKE_INSTALL_PREFIX=/usr ../kdelibs

When we were still early in the KDE 4 cycle, the following got reported as a 
bug: somebody was building some package, maybe kdebase into the same prefix as 
kdelibs, i.e. user:
cmake -DCMAKE_INSTALL_PREFIX=/usr ../kdebase

This installed its libraries into /usr/lib (instead of /usr/lib32 as kdelibs), 
the plugins into /usr/lib/kde4/plugins/, etc., i.e. into the default 
directories, not those which had been used for kdelibs.

It was expected that the install directories for any package in KDE SC which 
depends on kdelibs automatically use the same settings as were used for 
kdelibs.
So I implemented this:
http://quickgit.kde.org/index.php?p=kdelibs.git&a=commit&h=d5aba8d595d04e271fbb49866637e83a557c18b1
As can be seen, it requested (at least) by Volker Krause, and I got an 
additional "Thanks" email from Matt Rogers.

This also makes sense, since kdelibs not only provides libraries containing 
classes and functions, but also infrastructure, e.g. a directory structure 
where stuff has to be installed so that it works.

Without a common buildtime dependency for KF5 this functionality will be lost,
since currently there is no one package which defines the directory structure 
for a working KDE frameworks installation.

In extra-cmake-modules I added a KDEInstallDirs.cmake, which can pick up the 
directory structure from an already installed base package, but we don't have 
such a base package.

Additionally, finding/avoiding version hell
-------------------------------------------
Let's assume we have a libkcore in /usr/lib/, a libkui in /usr/lib/ and also 
in /usr/local/lib/ and a libsolid in /opt/lib/.

cmake will probably find /usr/lib/libkcore, /usr/local/lib/libkui and 
/opt/lib/libsolid.
Will this give a working combination ?
I'm afraid we run more into "dependency hell" which e.g. David would like to 
avoid.
Here is e.g. a thread from kde-buildsystem from May 2010 about such a problem, 
there were two sopranos installed, the one which was picked up did not work 
together with the kdelibs which was picked up:
http://lists.kde.org/?t=127345996200003&r=1&w=2

Now assume, as part of KDE frameworks we have a package KF5BuildSpecs, which 
installs maybe only one file, 
/usr/local/lib/cmake/KF5BuildSpecs/KF5BuildsSpecsConfig.cmake.
This file contains something like:

set(extra-cmake-modules_REQUIRED_VERSION 1.2.3)
set(Qt5Core_REQUIRED_VERSION 5.6.7)
set(KF5_COMMON_VERSION 5.1.0)
set(KF5_XDG_APPS_INSTALL_DIR /usr/share/apps/ )
set(KF5_LIB_SUFFIX "32")
...and maybe a few more settings.

Now let's also assume, every library part of KDE frameworks depends on this 
package (i.e. file, which might the same concept as the file you mentioned for 
the release process).
This solves a whole bunch of issues for us:
* we get a common set of install directories
* packagers have to define the install directory structure only once, for this 
package
* all KDE frameworks libraries can naturally all use a common version number
* all KDE frameworks libraries will share a common required Qt version (and 
others)

By sharing the install directory, we would ensure that KDE frameworks 
libraries which have been built "together", i.e. using the same KF5BuildSpecs, 
will also be found together, and probably work.

What would this mean e.g. for a tier2 library developer (kio ?)
---------------------------------------------------------------
For the case that he builds and installs all libraries he depends on himself, 
everything is fine. Thanks to the KF5BuildsSpecs, there is no doubt that cmake 
will find exactly those libraries he has installed.

Now let's say he has a KDE frameworks installation from his distribution and 
wants to build kio from git. How would that work.
Let's say he sets CMAKE_INSTALL_PREFIX to /usr, then it will build, and (if he 
has the permissions) install into the distro-installed set of KDE frameworks 
libraries. This mixes versions, and I doubt we should officially support this.

Let's say he sets it up so that it finds the installed KF5, and sets the 
install directories so that it installs into e.g. his home.
It will build, and install.
But the next time a package is looking for kio, it would normally find the one 
in /usr, since this is what KF5BuildSpecs says. In general this is a good 
thing, you get a working combination.
Can there nevertheless be a way to make cmake find his own kio ?
Probably, e.g. by presetting kio_DIR or something. This can be made possible.

What does this mean for a 3rd party application developer, who wants to use 
e.g. kio ?
---------------------------------------------------------------------------
He will search for the kio library, and find it together with the matching 
libraries it depends on in the same prefix. This is good for him.
By doing
find_package(kio)
this could in turn do find_package(KF5BuildSpecs).
So he would depend on the devel packages e.g. kio, kcore, and KF5BuildSpecs 
(and cmake and Qt and maybe extra-cmake-modules).
Since KF5BuildSpecs wouldn't be an actual library, this wouldn't add any 
runtime dependencies for his application.
He can add 
find_package(itemmodels)
or not, no problem.

Alternatively, doing
find_package(kio)
could also not include find_package(KF5BuildSpecs).
I don't know whether this would gain anything, but it would be less sure that 
he finds a matching set of libraries.

Library version numbering
-------------------------
Well, this is obvious.
KDE frameworks libraries do
find_package(KF5BuildSpecs)
and get the common version numbers they can use. Only one place to update 
them, no need to rely on script instead.

What disadvantages would such a buildtime dependency have ?

Alex