[Pacemaker] heartbeat vs. corosync installation confusion

[Vladislav Bogdanov]

09.03.2011 11:08, Lars Ellenberg wrote:
> On Wed, Mar 09, 2011 at 09:14:47AM +0100, Andrew Beekhof wrote:
>> On Mon, Mar 7, 2011 at 4:21 PM, Dennis Jacobfeuerborn
>> <dennisml at conversis.de> wrote:
>>> Hi,
>>> I'm planning to setup a redundant storage system using centos5, pacemaker,
>>> corosync, drbd, nfs and I'm wondering about the status of heartbeat vs.
>>> corosync when it comes to the installation of the pacemaker subsystem of the
>>> setup.
>>>
>>> From what I've learned lurking on the ML heartbeat is considered a "legacy"
>>> part of the stack that is supposed to be replaced by corosync so my plan is
>>> since this is a new setup to not bother with heartbeat and go straight for
>>> the new corosync route. When I install pacemaker though (using the
>>> clusterlabs rpms) it seems to not only pull in heartbeat automatically but
>>> also enable its init script by default. Is this intended?
>>> Can I safely disable the heartbeat init script when using corosync?
>>
>> yes
>>
>>>
>>> Why am I required to install heartbeat when I want to use corosync in its
>>> place?
>>
>> because it was built against both, and pulling in the libraries also
>> pulls in the main package.
>> not exactly optimal :(
> 
> I think that dependency nonsense has been fixed with more recent
> heartbeat packages.
> 

There was a long discussion about the (almost) same issue in openais ML
not so long ago with some packaging proposals and test from me:
https://lists.linux-foundation.org/pipermail/openais/2010-October/015245.html

There was a bugreport to Fedora Packaging Guidelines:
https://fedorahosted.org/fpc/ticket/20

It is now closed(fixed):
http://fedoraproject.org/wiki/Packaging/Guidelines#RequiringBasePackage

"-libs subpackages which only contain shared libraries do not normally
need to explicitly depend on %{name}%{?_isa} = %{version}-%{release}, as
they usually do not need the base package to be functional libraries."
And overall text is much less strict now.

Vladislav