HA_BIN backward compatibility

[kskmori]

This breaks the backward compatibility with the heartbeat stack.
#285 Low: build: Move binaries in /usr/lib/heartbeat to /usr/libexec/heartbeat to avoid multi-lib inconsistencies

The heatbeat init script expects the heartbeat binary resides in $HA_BIN/heartbeat (/usr/lib64/heartbeat/heatbeat) but it now tries to look /usr/libexec/heartbeat/heartbeat and fails.

[dmuhamedagic]

I'd vote to revert the commit 1e79b78 as this update would break the existing installations. @davidvossel: David, what do you say? Is that commit really that important?

[davidvossel]

The correct place for this sort of thing is libexec. It's weird that we are putting binary executables (things that are not libraries) in the /usr/lib and /usr/lib64 directories.

My primary reasoning for this change is to avoid the multilib conflicts that arise when building rpms of different architectures. Could we not add something to the build system to optionally place symlinks in the /usr/lib63/heartbeat directory to get around the backwards compatibility issue?

[dmuhamedagic]

On Thu, Oct 10, 2013 at 07:05:49AM -0700, David Vossel wrote:

The correct place for this sort of thing is libexec. It's weird that we are putting binary executables (things that are not libraries) in the /usr/lib and /usr/lib64 directories.

Perhaps Lars would know why that was the case with heartbeat. @lge, do you?

My primary reasoning for this change is to avoid the multilib conflicts that arise when building rpms of different architectures. Could we not add something to the build system to optionally place symlinks in the /usr/lib63/heartbeat directory to get around the backwards compatibility issue?

I think that you're missing the point here. There are heartbeat installations which expect the HA_BIN environment variable which is set in resource-agents to point to the directory where heartbeat's executables are placed. Hence, we cannot change HA_BIN at all. If we do so, the existing installations won't be able to start anymore.

Now whether that's technically right or wrong and how all packages coming from Heartbeat depend on each other is another issue.

[davidvossel]

I didn't realize heartbeat was coupled to resource-agents in that way. I can see why this breaks compatibility (regardless of how bad of an idea I think coupling these two projects like that is)

I guess we'll need a build system option for setting a custom HA_BIN directory then.

[l-mb]

I don't think it was an intentional coupling. resource-agents were split out from heartbeat and the two continued to use the same variable. Could, of course, be fixed by having newer versions of resource-agents conflict with older heartbeat versions.

[dmuhamedagic]

On Mon, Oct 14, 2013 at 01:06:13PM -0700, Lars Marowsky-Brée wrote:

I don't think it was an intentional coupling. resource-agents were split out from heartbeat and the two continued to use the same variable.

Right. And this is probably not the only variable. It may take
some serious analysis and quite a bit of time to find out what is
used where. Furthermore, privately developed RA source various
ocf-* scripts, so we should all think twice before moving things
around.

I'm not sure how to solve the multilib problem, I'm not even sure
what is it exactly. And why is it that we never had it before?
Also, on a recent pacemaker I still see
/usr/lib64/pacemaker/crmd.

[davidvossel]

All pacemaker components live in /usr/libexec/pacemaker/, all pacemaker tools live in /usr/sbin/. It has been this way since i started on the project (~2 years) , but it wouldn't surprise me if things were different in the past. Perhaps people are distributing it differently then we are in fedora/rhel for some distros.

The multilib problem boils down to this. We don't want scripts hardcoding references to different library or header locations based on what architecture it is built under. ocf-directories HA_BIN references /usr/lib/heartbeat for 32bit, and /usr/lib64/heartbeat for 64bit.

[dmuhamedagic]

We don't want scripts hardcoding references to different library or header locations based on what architecture it is built under.
Who's "We"? Why was this enforced on upstream when it seems to solve a specific distribution's packaging issue? Can we please have a better argument when breaking existing installations.