On Tue, Mar 24, 2015 at 4:13 PM, Orion Poplawski <[log in to unmask]> 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.