RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1113189 - pacemaker should list glib2-2.28 as a dependency
Summary: pacemaker should list glib2-2.28 as a dependency
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: pacemaker
Version: 6.6
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Andrew Beekhof
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On: 1101398 1139274
Blocks: 1641312
TreeView+ depends on / blocked
 
Reported: 2014-06-25 15:23 UTC by Radek Steiger
Modified: 2018-10-22 02:34 UTC (History)
9 users (show)

Fixed In Version: pacemaker-1.1.12-4.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1641312 (view as bug list)
Environment:
Last Closed: 2014-10-14 07:34:11 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1101398 0 unspecified CLOSED rebase glib2 to 2.28 2021-02-22 00:41:40 UTC
Red Hat Knowledge Base (Solution) 3661091 0 None None None 2018-10-22 02:34:42 UTC
Red Hat Product Errata RHBA-2014:1544 0 normal SHIPPED_LIVE pacemaker bug fix update 2014-10-14 01:21:31 UTC

Internal Links: 1101398

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
Note You need to log in before you can comment on or make changes to this bug.