CI Requirements - Lessons Not Learnt?

Alexander Neundorf neundorf at
Tue Jan 10 21:29:15 GMT 2017

On 2017 M01 6, Fri 17:20:08 CET Kevin Kofler wrote:
> PS:
> I wrote:
> > Martin Gräßlin wrote:
> >> For packagers it should not matter at all. This is the most common
> >> situation for distribution. And in the release of e.g. Plasma they have
> >> to handle this for hundreds of updated dependencies.
> >> 
> >> It's also not unexpected, because we have a dependency freeze in place
> >> prior to the release, thus the dependencies are announced way ahead.
> >> 
> >> It's only a "problem" for distros if they want to backport to an older
> >> release as in the case of Fedora. Honestly I consider this unreasonably.
> >> If you don't have a problem with backporting hundreds of packages I don't
> >> think that the one additional package is a problem.
> > 
> > The problem is that core packages such as xkbcommon are maintained by
> > different people than the Qt/KDE stack. It is not always possible for the
> > KDE maintainers to get such non-KDE dependencies updated in stable
> > releases (or in the worst case, even in Rawhide).
> An even more extreme example is Rex Dieter's efforts to provide current KDE
> packages for RHEL. There is little to no chance to getting a package such as
> xkbcommon updated in RHEL itself. So the repository ends up having to
> update not only software from KDE, but also several other packages.
> Obviously, the idea is to keep those at a minimum, not to replace half of
> the distro! It kinda defeats the point of rebuilding the KDE packages for
> RHEL if at the end you are essentially running the latest Fedora with .el7
> disttags.

At work we were just a few months ago updated to a "recent" installation. It's 
now a RHEL 7 with KDE 4.14. Before it was a SLES with a KDE 4.4 or something 
ancient like that.
So now, with the recent "update", I'm already again using basically obsolete 
software, since I guess e.g. kwin in 4.14 won't be fixed anymore (after 
switching to another virtual desktops kwin is busy for a few seconds before it 
reacts again).
It will probably take a few more years until we get a system with Plasma 5. 
> KDE software used to be much less demanding of the base system than the
> competition, it used to be easy to provide the software even for fairly old
> base systems such as RHEL n or even RHEL n-1. This has become much worse
> lately, with dependencies on bleeding-edge versions of: xkbcommon, Wayland
> libraries, etc. (And KWin is one of the worst offenders there, though
> definitely not the only one.)

there would be the pragmatic solution to (I know distros don't like that etc. 
etc.) to include a copy of the required xkbcommon library and link it 
statically if no matching version is found on the system. There could be an 
extra cmake switch to enable it...


More information about the kde-core-devel mailing list