Which package will provide the common KDE library version number ?

[Alexander Neundorf]

On Thursday 23 February 2012, Kevin Ottens wrote:
> On Wednesday 22 February 2012 21:52:24 Alexander Neundorf wrote:
...
> > 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).
> 
> Agreed, and a common production cycle gives us that...

No, it doesn't.
Once you end up running cmake on a system where you have one set of KDE 
frameworks libraries installed in some location (which will have the same 
version), and some other versions of other KDE frameworks libraries installed 
in other locations, things can get complicated and may break.
I'd like to avoid this.

> > > > > 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,
> 
> And having that in a common dependency creates the problems already
> highlighted ("version lies").


Depends.
Since there is no such thing as "KDE frameworks", but just a set of libraries, 
KF5BuildSpecs could be the one which defines this version number.
So whoever uses some version of KF5BuildSpecs, has by definition the version 
number provided by KF5BuildSpecs.

And whoever wants to use a separate version, is completely free to do so.
I mean, if we follow the scheme that the libraries will be developed and 
released together, then the version number is ok.

Additionally, the version number of a library can be different from the 
version number of the package. Not sure this would be a good idea though.

kcore could install as version 5.6.7, but use the version number coming from 
KF5BuildSpecs for its libraries.

I'm not sure this makes sense, but it's worth mentioning.

 
> > 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.
> 
> That I'd see more value to factor out indeed to simplify this very low
> level (from our perspective) common requirements. We'll have to be
> extremely careful about what go in there though.
> 
> Also I wonder how it looks for developers, it forces them to pull a single
> file outside of their module repo to be able to build which is... meh. I
> think in the java world nowadays things like that tend to be pulled
> automatically from an http server (and then locally cached), which forces
> internet access during the first build. If we're talking about a single
> file it could be something to investigate.

Yes, it's an option.
cmake has file(DOWNLOAD ...) e.g. from http, and it can also checkout sources 
from git or svn via ExternalProject.cmake.
(personally, I wouldn't like to need to have internet access to build a 
package)


...
> > 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.
> 
> Should be made possible IMO. We need to be able to allow people to work
> only on one framework if they wish to and rely on their distro packages if
> they want.

For those who want to combine an installed set of KDE frameworks libraries and 
override some of them with their own builds something can be done.
Like having to install an own KF5BuildSpecs into their HOME, which refers to 
the system wide installation in some way, but allows to override parts.

This would be an explicit set up from the developer, so he should be aware if 
he does something wrong.

 
> > What does this mean for a 3rd party application developer, who wants to
> > use e.g. kio ?
> > -------------------------------------------------------------------------
> > -- [...]
> > 
> > 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.
> 
> As stated above already: I'm fine with all the above cases except that one.

How will this be handled otherwise ?
There will be many repositories.
With kdelibs it was only one place where it had to be changed, this was easy 
to do.

There will be at least the required Qt version numbers, cmake version numbers 
and probably also extra-cmake-modules version numbers to keep in sync.
 
> I'm not against a build time dependency on principle (although as I hinted
> above we should make it as automated as possible to someone with only a
> single tarball), but I think it should not provided the common version
> number. That's because of this case that we create the "version lie"
> problem. It needs to go away.

Well, we had this one place with a central version number because people 
wanted to have it.
Changing the library version numbers everywhere separately was not considered 
a good option.
I actually don't think this has changed.
 
> I'd be fine with a "find_package(KF5BuildSpecs 5.3.0)", assuming the
> version number would be mandatory, as now there'd be no risk of a
> kwhatever 5.3.0 claiming to be a kwhatever 5.10.0.

This can be done.
Then this line has to be kept in sync in all repositories in some way.

And whatever we do, without a common, (possibly optional) "root" dependency we 
will loose the "pick up install directories from kdelibs" feature, AFAICT.

I'll try to build some prototypes.

Alex