[Debian-ha-maintainers] Bug#981088: pacemaker: crm shell can't be executed due to a library error

[wferi at niif.hu]

Markus Koschany <apo at debian.org> writes:

> Am Freitag, den 26.03.2021, 16:37 +0100 schrieb wferi at niif.hu:
>
>> Thorsten Rehm <thorsten.rehm at ionos.com> writes:
>> 
>>> In my opinion the crmsh package should be more strict with the
>>> pacemaker-cli-utils package
>> 
>> Sorry for not looking into this sooner.  What do you mean by being
>> "more strict"?  Does crmsh require a specific version of
>> pacemaker-cli-utils to function correctly?
>
> Yes, exactly. There should be a versioned dependency on
> pacemaker-cli-utils.

What kind of versioned dependency?  What's your source?  I don't
maintain crmsh, so I'm not familiar with its requirements.

>> While that's possible, I don't think it has anything to do with your
>> problem, which is that crm_mon requires the libpe_status.so.10 shared
>> library, but that is not provided by the 1.1.24-0+deb9u1 version of
>> libpe-status10.  Because it switched to providing libpe_status.so.16
>> instead.  The library changed SONAME, but the package name did not
>> change, which is forbidden.  The same applies to libpengine10.
>> 
>> Markus, I know introducing new packages through the security channel
>> is highly unusual, but is it entirely impossible?  Or can you
>> recommend some other solution?
>
> In my opinion this issue has been resolved in Stretch. It's up to you
> if you want to tighten the dependency on pacemaker-cli-utils in
> unstable releases but we don't need to change that in Stretch right
> now.

I wonder if pacemaker Recommending the same version of
pacemaker-cli-utils would have helped here...  probably not.
Switching to Depends isn't unreasonable, but not compelling either.

> Pacemaker works fine, there was just a corner case when some packages
> were put on hold hence my suggestion to tighten the dependency.

You needn't put anything on hold to reproduce this problem.  Just
install pacemaker-cli-utils from stretch, then upgrade libpe-status10
from stretch-security, and crm_mon can't start anymore.  Surely it isn't
a common scenario, and any affected users are probably past this by now,
but this is the gist of the problem.  We may leave it at there, though.

> We usually don't change package names in oldstable releases. In this
> case there were no other reverse-dependencies which had to be
> rebuilt. If there were any we would just rebuilt affected packages.

I see.  This still risks breaking software built by the user, because it
violates Policy 8.1: "The run-time shared library must be placed in a
package whose name changes whenever the SONAME of the shared library
changes."  Anyway, we have to find out if there's anything to do here.
-- 
Thanks,
Feri