On Thu, Mar 26, 2015 at 5:59 AM, Tom H <[email protected]> wrote: > On Tue, Mar 24, 2015 at 4:13 PM, Orion Poplawski <[email protected]> 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.
