On Thu, Mar 26, 2015 at 5:59 AM, Tom H <[log in to unmask]> wrote:
> On Tue, Mar 24, 2015 at 4:13 PM, Orion Poplawski <[log in to unmask]> wrote:

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

What? No, SL and CentOS *inherit* this behavior from Red Hat's minor
point releases. Our favorite upstream vendor has moved away from the
old practice, long before RHEL, of the point releases being supported
individually long term, but they certainly publish new installation
media with the new point releases. The big difference is that SL and
CentOS continue to publish the point releases in different web
accessible directories, so you can still see the point releases and
updates segregated by time, and releases they were compatible with.
RHEL publishes all the updates since the first point release in a
giant pool, more like the SL 6x and 7x repositories: it can provide
some really useful information about the point releases to compare
thei contents among them.

When you lack the QA and pre-release testing of a major vendor, it can
be really helpful to keep things seggregated, especially when you're
always playing catch-up with upstream and the point releases contain a
large mass of updates which may take you some time to resolve.