CI Requirements - Lessons Not Learnt?

[David Faure]

On jeudi 5 janvier 2017 21:44:23 CET Ben Cooksley wrote:
> Hi all,
> 
> It seems that my previous vocal complaints about system level /
> serious impact dependency bumps on the CI system have gone completely
> unnoticed by (some) members of our Community.
> 
> This was demonstrated earlier this week when components of Plasma
> bumped their version requirements for XKBCommon and Appstream-Qt -
> without even a thought about notifying Sysadmin or checking which
> version the CI had, until their builds broke.
> 
> Neither of these is easy to fix at this stage, as the system base is
> now too old to receive updates such as these. Base upgrades require a
> full rebuild of everything on the CI system, and usually involve
> significant additional churn and is a process that must be done
> roughly twice a year, depending on dependency bump demands.
> 
> Does anyone have any suggestions as to how we may avoid this in the future?
> 
> At this point i'm in favour of if you don't follow the rules your
> dependency bump just gets reverted out of existence, then you get to
> go through the process properly...

I agree that this is very annoying, it broke my own builds too and I complained
to Martin Graesslin already ;)

One thing though: note that you don't need to upgrade the base system to
get a newer xkbcommon. It's a lib that can be installed into a custom prefix.

My kdesrc-buildrc simply has this additional block, which solved the local compiling issue:

# OpenSuSE Leap 42.2 has libxkbcommon-devel-0.6.1-1.4.x86_64, but kwin requires 0.7
module libxkbcommon
  repository git at github.com:xkbcommon/libxkbcommon.git
  tag xkbcommon-0.7.0
end module

But you're asking about the more general issue of how to avoid breaking the CI,
and that indeed requires people to notify sysadmins when upgrading requirements.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5