Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HA_BIN backward compatibility #330

Open
kskmori opened this Issue Oct 10, 2013 · 8 comments

Comments

Projects
None yet
4 participants
@kskmori
Copy link
Contributor

commented Oct 10, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Oct 10, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Oct 10, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Oct 11, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Oct 14, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Oct 14, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Oct 15, 2013

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

This comment has been minimized.

Copy link
Contributor

commented Oct 15, 2013

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.

kskmori added a commit to kskmori/resource-agents that referenced this issue Aug 15, 2014

Medium: Build: add --compat-habindir option for HA_BIN backward compa…
…tibility

This configure option is to be used when the package is used
for the existing Heartbeat stack.

As of the commit below, HA_BIN directory has been changed to
more appropriate location but it introduces an incompatibility
so the Heartbeat stack would fail to start.
  ClusterLabs#285

See also:
 ClusterLabs#330
@dmuhamedagic

This comment has been minimized.

Copy link
Contributor

commented Aug 19, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.