SCIENTIFIC-LINUX-USERS Archives

March 2015

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
John Pilkington <[log in to unmask]>
Reply To:
John Pilkington <[log in to unmask]>
Date:
Fri, 27 Mar 2015 10:04:26 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (49 lines)
On 27/03/15 08:53, Tom H wrote:
> On Thu, Mar 26, 2015 at 7:28 AM, Nico Kadel-Garcia <[log in to unmask]> wrote:
>> 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.
>
> I agree with your last point. RHEL and CentOS use the equivalent of
> SL's 6x/7x by default and don't give the option of using 6.y/7.z.
>
> Point releases are just a snapshot of the packages at a certain point
> in time, like Debian 6.x/7.x and Ubuntu 12.04.x/14.04.x.
>
> RHEL offers its customers an EUS program for them to remain at a point
> release and get security updates but it doesn't publish the EUS
> sources in the same way that it doesn't publish the ELS sources.
> -
But my original point was that glib2-2.36.3-5, which I see in SL7x, was 
incompatible with the new (in epel-testing) qtwebkit, which needed 
glib2-2.40.0-4 from SL7rolling built off TUV's 7.1

It seems that what I see as SL7x is still 7.0.  The naming of the 
download sites may have me confused.  I'm using yumex.

ATOM RSS1 RSS2