On Tue, Mar 24, 2015 at 4:13 PM, Orion Poplawski <or...@cora.nwra.com> wrote: > On 03/19/2015 03:34 AM, John Pilkington wrote: >> >> I had been under the impression that it was likely to be safe to use 'epel' >> packages, so, wishing to provide feedback, I installed a new version of >> qtwebkit from epel-testing. No hint of problems during installation, but >> programs using it failed. I now have them apparently working after installing >> glib2 from SL7rolling in place of the earlier build in SL7x, but I'm less >> than >> happy about such cherry-picking. >> >> I'm told that epel packages support the current upstream release, 7.1, so it >> seems to me that systems based on the recommended SL7x and using epel will be >> at risk. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1202735 > > The ultimate cause of this issue was an upgrade of glib2 by RedHat in RHEL > 7.1. And because the glib2 library does not use symbol versioning, rpm cannot > automatically add the proper requires/provides to avoid installing > incompatible libraries. So, this has nothing to do with EPEL, per se, but > just normal issues that can occur with any update to RHEL.
Rex Dieter (who's a Fedora and EPEL developer; it's too bad that the RH bugzilla instance doesn't add a "dev" icon to developers' names like the Gentoo one) explains in comments 5 and 7 why they don't do this. They don't need to because sticking to a specific point release is an SL quirk that's not supported by RHEL. So a RHEL user wouldn't hit this qtwebkit/glib problem and EPEL's developers don't waste their time ensuring that's it works.