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