CI Requirements - Lessons Not Learnt?

[Kevin Kofler]

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.

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

        Kevin Kofler