Which package will provide the common KDE library version number ?

[Kevin Ottens]

On Thursday 23 February 2012 21:23:00 Alexander Neundorf wrote:
> On Thursday 23 February 2012, Kevin Ottens wrote:
> > On Wednesday 22 February 2012 21:52:24 Alexander Neundorf wrote:
> ...
> > 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.

Which is the the situation we should avoid IMO. It's what I call a version 
lie...

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

Ah interesting, in such a case it'd download every time? Or it would cache the 
result somewhere?

If we go for something like that it should IMO be something like:
 * Look in the system if the file is already there;
 * If not look in the local cache (in case we pulled already);
 * If not then downloads

Of course it's likely something which should be in cmake itself or ECM. 
Otherwise we have easily a dependency cycle for that feature or we duplicate 
it in each module... not great. :-)

(BTW, I'm not saying it should be implemented before we release, but if 
there's some feasibility there, it'd be a nice thing to improve our developer 
story later on)

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

As long as it's easy. :-)

People needing this usecase are the typical "I just want to modify that tiny 
bit and not be bothered". Definitely not the die hards of our community who 
can pull a whole set of libs.

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

As I said several times already: I'm not against a common dep for all those 
dependencies to be kept in sync or the install dir handling. I just don't want 
the library version number to be picked from that common dependency to forbid 
"version lies" which already created problems with our downstreams.

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

Which made sense at the time, we had "only kdelibs" anyway and applications 
directly on top (which were carrying their own version number)... except 
really we were fooling ourselves as soon as things like kdepimlibs appeared, 
we traded convenience for potentially screwing up downstreams.

> I actually don't think this has changed.

Yes it does, now the problem won't be just kdelibs vs kdepimlibs (or such) if 
we keep setting the version number the current way, but "common build time 
dep" vs any kwhatever (and they'll be plenty, so more opportunities than ever 
to screw up if you're a downstream).

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

Excellent!

> Then this line has to be kept in sync in all repositories in some way.

Yes, that's the obvious price to pay. Hence why I was mentionning a script 
earlier. That said if the version check can be a "==" as soon as we flip it in 
the common dependency most of our devs will notice (as the build will break) 
and will have to change on their side (I expect most of them to just clone and 
then get the greatest, CI as well). It's even trivial enough to fix.

Now automating is better indeed and should be pursued.

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

Which I never advocated to remove... Now ideally this should be contained in a 
small single file, so that *later on* we can try the "download me 
automatically" idea we're toying with above to make it as painless as 
possible.

> I'll try to build some prototypes.

Excellent! Thanks for that.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120224/f296a269/attachment.sig>