Ben Cooksley wrote: > On Thu, Jan 5, 2017 at 10:28 PM, Martin Gräßlin wrote: >> It should be rather obvious that we don't introduce new dependencies >> because we like to. There is a very important software reason to it. >> That's the case for the xkbcommon dependency increase. Should I have let >> the code broken as it was, expecting half a year of bug reports till >> build.kde.org has the base upgraded to Ubuntu 16.04? > > That's what #ifdef is for...
+1 The new xkbcommon requirement is also an issue for us in Fedora. The new xkbcommon 0.7.0 is only available in Rawhide and it is doubtful that it will ever be backported to Fedora 25 or 24. So, if we cannot get libxkbcommon updated, we will either be unable to provide your new Plasma releases for our stable releases, or we will be forced to add a patch to revert your dependency bump, as we already had to do for Qt in the past: http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtbase.git/tree/qtbase-opensource-src-5.3.2-old_xkbcommon.patch?id=e26fd4ffda851bfe13d975547e218e16f72ce556 (Yes, this reintroduced a bug. It was just not possible to fix that bug with the xkbcommon that was available in the Fedora 19 release. Fedora 20 eventually got the xkbcommon update, so we were able to drop this patch there. We still had to patch Qt for the old xcb-xkb (which could not be updated due to a soname bump) though.) >> Similar for Mesa 13 which I'm also eagerly waiting for build.kde.org to >> fetch it. > > Mesa 13 is news to me. This is also an issue for us: Mesa 13 is only available in Fedora 25 (updates) and Rawhide, not in Fedora 24. Kevin Kofler
