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

[Markus Koschany]

I'm dropping the bug submitter from CC because I believe the discussion is no
longer relevant for him.

Am Freitag, den 26.03.2021, 21:08 +0100 schrieb wferi at niif.hu:
> Markus Koschany <apo at debian.org> writes:
[...]
> > 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.

One could add a versioned dependency like that 

pacemaker-cli-utils (>= 1.1.24-0+deb9u1) and then tighten this version to
whatever version is the latest for each distribution. Since you are not the
maintainer of crmsh, this is a bit inconvenient to maintain and there is a
better solution.


> 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.

You could change the Recommends to pacemaker-cli-utils (= ${source:Version})
which would have prevented the problem. This is probably the simplest solution.

> 
> > 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.

This scenario is unrealistic because you would install pacemaker-cli-utils also
from stretch-security because of the pinning priority. Under normal conditions
an upgrade of pacemaker would pull in all needed dependencies in Stretch. As I
said the problem here was that dependencies were intentionally put on hold by
the bug submitter.


> > 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."  

Stretch is a LTS release now and we have to weigh our options. Normally we
don't upgrade packages to the latest upstream release but try to find targeted
fixes. This didn't work in case of pacemaker. Next we try to assess how
disrupting a new upstream release would be and if the security fixes outweigh
possible regressions. In this case it was more important to fix the security
vulnerabilities in pacemaker. Changing the package name was not really
necessary because there are no reverse-dependencies. All those libraries are
part of the same source package.

> Anyway, we have to find out if there's anything to do here.

I don't think there is anything to do in Stretch for now.

Regards,

Markus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/debian-ha-maintainers/attachments/20210326/5a282147/attachment.sig>