31.10.2022 19:14, Michael Stone wrote:
If you can come up with a better solution than a strict dependency, great. But the current situation, in which samba upgrades randomly render systems unusable is, in my opinion, much much much worse than an overly strict dependency. Fundamentally the problem is that you're promising future compatibility but not providing that. One way or another samba-libs either needs to not suggest that linked binaries will work with future versions, or make sure that they do.
Heck. I did some modifications to the packaging, added the right Breaks: against an "old" sssd-ad, which should close this very bugreport. But. And this is a big fat BUT. I also adjusted list of samba-libs files in samba-libs.install to include all sonames explicitly. And this revealed one more issue here, now with samba 4.17. Where, the same libndr.so again, has changed soname from libndr.so.2 to libndr.so.3! And it looks like *this* is what you're talking about now, once 4.17 with this new libndr.so.3 hits unstable. *Sigh*. So now, samba-libs breaks not only bullseye sssd-ad, but also *bookworm* sssd-ad! So: samba-libs 4.13: libndr.so.1 samba-libs 4.15: libndr.so.2 samba-libs 4.17: libndr.so.3 and this is what we're facing now, 4.16=>4.17 update breaks things again. and this new breakage went unnoticed, and I knew nothing about the soname change before this very moment. Andrew, can you share some info about the new 2=>3 soname bumb in 4.17? I wonder if we should provide old libndr.so.1 and libndr.so.2 interface in samba-libs forever... this shouldn't be that difficult. /mjt
