Bug 1113189

Summary: pacemaker should list glib2-2.28 as a dependency
Product: Red Hat Enterprise Linux 6 Reporter: Radek Steiger <rsteiger>
Component: pacemakerAssignee: Andrew Beekhof <abeekhof>
Status: CLOSED ERRATA QA Contact: cluster-qe <cluster-qe>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 6.6CC: cluster-maint, dvossel, fdinitto, jkortus, mclasen, nwahl, tlavigne, tpelka, walters
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: pacemaker-1.1.12-4.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1641312 (view as bug list) Environment:
Last Closed: 2014-10-14 07:34:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1101398, 1139274    
Bug Blocks: 1641312    

Description Radek Steiger 2014-06-25 15:23:27 UTC 
Description of problem:

In RHEL6.6 the glib2 version is being bumped to 2.28 and the new pacemaker 1.1.12 is linking a new symbol g_list_free_full which is not available in the previous glib2 version. This might cause an issue when upgrading pacemaker from 1.1.10 to 1.1.12 on a RHEL6.5 system.

The pacemaker package will upgrade seamlessly however it doesn't list the new glib2 version as a dependency...

# rpm -qR pacemaker | grep glib
libglib-2.0.so.0()(64bit)

...and when the admin attempts to upgrade just pacemaker only, it will not pull the new glib2 libs and cib will never be able to start:


With OLD glib2:

# rpm -q pacemaker glib2
pacemaker-1.1.12-3.el6.x86_64
glib2-2.26.1-3.el6.x86_64

# nm -D /lib64/libglib-2.0.so.0 | grep g_list_free_full
# 

# /usr/libexec/pacemaker/cib
/usr/libexec/pacemaker/cib: symbol lookup error: /usr/lib64/libpe_rules.so.2: undefined symbol: g_list_free_full
# echo $?
127


With NEW glib2:

# rpm -q pacemaker glib2
pacemaker-1.1.12-3.el6.x86_64
glib2-2.28.8-1.el6.x86_64

# nm -D /lib64/libglib-2.0.so.0 | grep g_list_free_full
000000000003e320 T g_list_free_full
#

# /usr/libexec/pacemaker/cib
# echo $?
100



How reproducible:
Always


Steps to Reproduce:
1. Install RHEL 6.5
2. Add RHEL 6.6 repos
3. Update pacemaker to 1.1.12
4. Try to start a cluster, or just run /usr/libexec/pacemaker/cib


Actual results:

Glib2 library is not upgraded and pacemaker fails to start.


Expected results:

Pacemaker should list the new glib2-2.28 version as a hard dependency so they always get upgraded together.
Comment 2 Andrew Beekhof 2014-06-26 10:11:27 UTC 
I'm confused... rpm is supposed to generate those dependancies automatically.
If we built against libglib-2.0.so.0 then that should be picked up by rpm and yum should honour it.

What gives?
Comment 3 Colin Walters 2014-06-26 11:33:44 UTC 
(In reply to Andrew Beekhof from comment #2)
> I'm confused... rpm is supposed to generate those dependancies automatically.
> If we built against libglib-2.0.so.0 then that should be picked up by rpm
> and yum should honour it.

Only for libraries that use versioned symbols, which GLib does not.  The only current way to solve this is to not use e.g. GLIB_CHECK_VERSION(), or alternatively, have a master -DGLIB_VERSION_MAX_ALLOWED (as is in newer upstream glibs) to say which version you want to target at compile time.
Comment 4 Andrew Beekhof 2014-06-27 01:56:10 UTC 
Pacemaker can happily use both old and new versions of glib2, the only requirement pacemaker has is to use a version >= the one it was compiled against.

That I would need to keep track of the latest glib2 version and update the pacemaker spec file with it every time I build seems clumsy to me.  Surely there is a better way.
Comment 5 Matthias Clasen 2014-06-27 12:27:57 UTC 
The simple fix is the best here: just add a Requires: glib2 >= 2.28 to the spec file.
Comment 6 Andrew Beekhof 2014-06-30 00:03:52 UTC 
IMHO, anything that requires on-going action doesn't qualify as a fix
Comment 7 Colin Walters 2014-06-30 00:52:15 UTC 
(In reply to Andrew Beekhof from comment #6)
> IMHO, anything that requires on-going action doesn't qualify as a fix

You only have to update the Requires once per rebase, and only if pacemaker uses newer APIs.
Comment 8 Andrew Beekhof 2014-06-30 01:42:47 UTC 
1. It was a rebase of someone else's package
   - will maintainers be sending out emails to dependant packages in advance of their rebases now, or will we still find out at the 11th hour when people try to install?

2. It was an API that we started using in our codebase over 2 years ago
Comment 9 Colin Walters 2014-06-30 01:48:10 UTC 
(In reply to Andrew Beekhof from comment #8)
> 1. It was a rebase of someone else's package
>    - will maintainers be sending out emails to dependant packages in advance
> of their rebases now, or will we still find out at the 11th hour when people
> try to install?

I will do that in the future.
Comment 12 errata-xmlrpc 2014-10-14 07:34:11 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1544.html