[Pkg-openldap-devel] Bug#725153: Bug#725153: Bug#725153: openldap, nss, and gnutls

[Timo Aaltonen]

09.04.2016, 19:19, Ryan Tandy kirjoitti:
> Control: tag -1 = patch
> 
> On Sat, Apr 09, 2016 at 06:10:16PM +0300, Timo Aaltonen wrote:
>> 09.04.2016, 09:12, Ryan Tandy kirjoitti:
>>> What happens if both copies of libldap somehow end up linked into the
>>> same process? I don't know freeipa well enough to imagine a specific
>>> scenario, but it probably involves PAM somehow... Looks like curl
>>> handles this via renaming the symbol versions, we could probably do the
>>> same, if needed.
>>
>> Hmm right, I didn't notice the symbol renaming in curl though I used it
>> as an example for how to build separate versions.. so it just needs
>> changes in .symbols?
> 
> The versioning script needs a change:
> 
> http://sources.debian.net/src/curl/7.47.0-1/lib/libcurl.vers.in/
> 
> I'm not sure where that gets replaced, but that's what needs to be set.
> And then, yes, symbols needs to be updated to match.
> 
> In our case, OpenLDAP upstream doesn't use symbol versioning, so our
> version script is in debian/patches/libldap-symbol-versions.

Ahh, ok.. so for moznss the .map files would have OPENLDAP-NSS_2.4_2 for
the NSS build. I've added that.

Btw, the tar & patch approach makes it easier to clean up afterwards.
Building from the same root would mean unapplying nss-build.diff on
clean and that might be fragile. Using quilt and keeping the patch last
on series makes adding patches to need a bit more work. But if you
prefer this more then I can make that happen.

I've pushed new commits to the branch trying to address all the things
you've mentioned. But looks like #726116 might make all of this too
early. That said, 389 and IPA do use their own certificate db's, but I'm
not sure if the systemwide certificates should be available to them. I
need to ask upstream.

>> Should be ABI compatible, which comment are you referring to?
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725153#60
> 
>> Well, my quick testing shows that a simple library swap isn't enough,
>> but 389 probably needs a rebuild against the new lib.
> 
> Doesn't matter anyway, if we're changing the symbol versions it's no
> longer hot-swappable, and I think changing those is probably safer.

Oh, that was when we were testing libldap-2.4-2 built against nss. I
don't know if it needed a rebuild.. maybe. But in this case that doesn't
matter as you said, it needs a rebuild in any case.

Thanks for the review and comments so far!

-- 
t