Background: Fedora Rawhide has unified /usr/bin and /usr/sbin. An upgrade from F41 keeps the directories separate, while I presume that a fresh installation would have a single directory.
- Changes/Unify bin and sbin - Fedora Project Wiki
- FEDORA-2025-da0a082e66 — enhancement update for bin-sbin-merge — Fedora Updates System
I’m a maintainer of the Pacemaker cluster resource manager.
If you insist on going through with this merge of directories, then Pacemaker must override it within our spec file, and continue using /usr/sbin as our default _sbindir.
How would you recommend we do this override, without introducing corner cases when building Pacemaker on other distros and older Fedora releases? I see that macros.filesystem uses %if "%{_sbindir}" == "%{_bindir}" as the check. I can envision a corner case in which a user has explicitly overridden both of them to be equal, or where this happens on some obscure other distro that I’m not aware of. I guess we could check for equality and then also compare against the string /usr/bin or %{_exec_prefix}/bin, and then set _sbindir to /usr/sbin… but again, if a user has explicitly specified _sbindir = /usr/bin, I would want to respect that. Likewise, I’m not sure what I’d want to do if _exec_prefix has been user-specified.
We’re aware of two ways this breaks Pacemaker so far.
- It causes resources to restart unnecessarily. I can provide more details about the mechanism upon request, but it’s complicated. Suffice it to say that part of the cluster resource configuration is generated on the fly; one resource parameter value is based on the
sbindirconfigure constant; and any change to a resource parameter causes a checksum change, which forces the resource to restart. This is deeply embedded in Pacemaker’s design, and there are reasons for it. It’s not feasible to change the design, especially because of compatibility issues.
Now, this is a problem because the purpose of the software is to maintain high availability. In particular:
a. It would cause an additional resource restart during rolling upgrades from pre-Fedora 42 Pacemaker builds.
b. It breaks Pacemaker builds on Fedora Rawhide (because it breaks several regression tests, which check whether restarts would occur under certain circumstances).
- It breaks Pacemaker guest nodes by default. Pacemaker allows the configuration of docker/podman containers as “guest nodes” within “bundle resources.” We support basically arbitrary OS distros, OS versions, and Pacemaker versions within the container. By default, when Pacemaker starts a container, it runs
/usr/sbin/pacemaker-remoted(based on thesbindirconfigure variable) on the container. But now, if the host has been upgraded to Fedora Rawhide, it tries to run/usr/bin/pacemaker-remotedon the container. Nothing exists at that path on the container, so the guest node fails to start. We can’t just toss a fix into thepacemaker-remoteinstallation, because we support running older versions (almost arbitrarily old) on the containers.
We may find still more things that break; this is what we’ve seen so far.
I appreciate any guidance here, thank you.
I would have replied to F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide) - #30, where my colleague Michal reported breakage of pcs (a management tool for Pacemaker). However, that topic has been closed and I cannot reply.
Please remove any irrelevant tags and add any further ones needed.
We need to try to find a solution such that anything that previously worked continues to work. I’m trying to do that without introducing new corner cases and without missing some obscure case.