Which package will provide the common KDE library version number ?

Thu Feb 23 13:42:15 UTC 2012

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

Hey, don't turn the table now. You asked the question in the first place, you 
wanted just a yes or no from us. ;-)

So, yes they can (of course doesn't necessarily mean we as frameworks 
maintainers want the burden to test all possible combinations).

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

Well, that's beside the point. Not saying your proposal would prevent it, just 
saying your proposal is bound to recreate the issue Sune raised earlier in 
this thread: if my kwathever framework coming from kwhatever-5.1.2.tar.bz2 
happens to find the common dep you want to introduce in version 5.3.0, then 
AFAICT the result of my kwhatever build will claim being 5.3.0... While 
clearly it's not the right code.

We really should solve this problem IMO.

But I don't see that solved by avoiding the versioning being in the main 
CMakeLists.txt of each of frameworks modules in one form or another. That is 
either by carrying the version number itself *or* using a common dep *but* for 
which you specify which exact version you want.

For the second possibility with your proposal it'd mean using:
find_package(KF5BuildSpecs 5.3.0)
and not
find_package(KF5BuildSpecs)

Version would be mandatory there.

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

I don't think we'll end up with the same dependency issues as the aim is still 
to have a common cycle for all of them. Although you can here me advocate that 
decoupling KDE Frameworks release cycle to KDE Apps or KDE Workspaces release 
cycles... I really think all the frameworks should be part of the same cycle.

As pointed out earlier: we now technically allow to mix frameworks in 
different versions (or pick only a subset of the offering), we don't want to 
support the burden though and our cycle will assess that.

> 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

To me it sounds more like a backfire on the versioned folder, not for 
integrated versions. :-)

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

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

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

Note however that I'm on purpose not settling on a definitive solution. It's 
important for that particular issue to not hinder the developer story for all 
parties:
 * frameworks developers (ranging from the whole lot available to only having 
a single framework cloned);
 * KDE application developers (who tend to have the whole lot available to 
them);
 * Qt+addons application developers (who want only Qt and one or two addons).

> Install dirs:
> ------------
> [...]
> 
> Additionally, finding/avoiding version hell
> -------------------------------------------
> [...]
> 
> 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.

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.

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

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.

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.

Hope that clarifies.

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/20120223/08686707/attachment.sig>