Comment 12 for bug 1584485

I don't believe the debdiffs provide a valid solution to this issue. Here is an irc discussion with infinity where he presented a better solution:

<mdeslaur> infinity: I'd appreciate your thoughts on the best way to address bug 1584485
<mdeslaur> infinity: that approach doesn't look sane to me, do you have any suggestions for something better?
<infinity> mdeslaur: The proposed fix is certainly not reasonable. I'll ponder the problem over breakfast.
 mdeslaur: Is it a question of ABI breaks, or ABI additions? It seems the real issue is bad dependencies between libnss-winbind and its deps.
<infinity> Oh, because samba-libs is a big blob os libraries that shouldn't be packaged together.
 Whee.
<mdeslaur> infinity: if the abi changes, running processes die because they're running with the old version of libnss-winbind
 infinity: I guess abi additions should be fine, but I'm not sure how careful samba preserves abi between versions
<infinity> mdeslaur: Running processes should be fine, it's new processes that explode miserably. (Well, or running processes calling into NSS anew, but that's still "new", from my POV)
<infinity> mdeslaur: But yeah, the problem is clearly a lack of sane ABI versioning on "samba-libs" and, thus, incorrectly weak deps between libnss-winbind and samba-libs.
 mdeslaur: Doesn't look like something one can properly fix in an SRU, since the fix is to actually version the *#^)! libraries correctly.
<mdeslaur> oh, right, new processes in that specific case
<infinity> mdeslaur: But having samba-libs Break libnss-winbind << Binary-Version, and disable/reenable winbind on preinst/postinst would "work". Though, gross.
<mdeslaur> I thought I saw a bug where existing processes were crashing because of an incompatibility with a newer winbind service
<infinity> Existing processes will also explode if they call into NSS fresh, NSS is effectively a dlopen().
<infinity> But yeah, I consider dlopen "new processes" from the POV of hunting library ABI issues. :P
 Otherwise my head hurts.
<infinity> Anyhow, any solution that halts upgrade with "we notice you have packages installed and you're actually using them correctly; please stop using them" is not sane.
 If it can be automated to disable/reenable, that's vaguely okay, though if their setup relies on winbind resolution working, there's a gap there where the world sucks.
 But better that than crashing, I suppose.
<mdeslaur> infinity: but what happens when an existing process is running with an old libnss-winbind, and the windbind package gets upgraded to a version that is not compatible with the old libnss-winbind?
 perhaps that's not a problematic scenario
<infinity> mdeslaur: After taking a walk, it occurs to me that in the absence of proper library versioning, the more robust solution might just be for nss-winbind and pam-winbind to be statically linked to samba-libs.
 mdeslaur: That would eliminate the problem, and have the added bonus of not having to pull in a massive samba-libs package just for the small bits that the nss/pam plugins need.
<mdeslaur> hrm, that does sound reasonable