Markus Koschany <a...@debian.org> writes: > Am Freitag, den 26.03.2021, 16:37 +0100 schrieb wf...@niif.hu: > >> Thorsten Rehm <thorsten.r...@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
