CI Requirements - Lessons Not Learnt?
kevin.kofler at chello.at
Fri Jan 6 16:20:08 GMT 2017
> 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.
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.)
More information about the kde-core-devel