[Pkg-openldap-devel] OpenLDAP 2.4.7 [was, Re: Proposed layout for svn.]

[Steve Langasek]

On Sat, Dec 15, 2007 at 03:35:42PM -0800, Russ Allbery wrote:
> Steve Langasek <vorlon at debian.org> writes:

> > 1) get symbol versioning support into the package for libldap, so that we
> >    cut down the segfaulting with partial upgrades

> Yeah, I was wondering about that.

First stab at this is committed to svn now.  The patch is far from something
I'd want to try to submit upstream, but it at least eliminates this as a
blocker for uploading to unstable.

I also fixed the problem that libldap and libldap_r were both being shipped
for openldap2.3, where we only want to have to support one copy on the
system.  There's also libslapi as a shared lib; I don't know what the
implications are of including this in the libldap-2.4-2 package, but at
least for the moment that seems better than moving it to the slapd package.
If someone feels differently, please shout (or commit).

... and then I went and made the change to build-depend on libgnutls-dev
instead of libssl-dev which I'd forgotten to do before, and now the package
FTBFS. :)  Looks like this is related to having support for lanman password
hashes enabled; I would recommend simply disabling these, since these are a
horribly weak, pre-NT encryption (not NT and above, as the bug submitter
claimed when requesting this feature be enabled).

> > 3) proper upgrade support for 2.3.39->2.4.7 databases

> This should be a simple matter of tweaking the version restrictions in the
> scripts to say that such a database has to be dumped and restored, since
> there are no schema changes or the like, I think.

This is also done now.

> > 4) upgrade testing
> > 5) install testing
> > 6) decide what other package handling, if any, needs to be put in place in
> >    response to slurpd being dropped (I guess someone who's used syncrepl
> >    should provide input here, since I have not)

> We're using delta-syncrepl with something very close to the current Debian
> packages without any trouble, so I don't think you'll need any other
> packaging.

So you don't think there's a need to detect when users have slurpd enabled,
and provide some warning that it will cease to be available on upgrade and
require manual adjustments?  Debconf error template, NEWS.Debian or
something?

> We should probably apply the patch in the BTS to support cn=config, or at
> least do something with that request, since upstream is moving towards
> semi-deprecating the old configuration file.  I don't think we're at the
> point where we should be converting people's slapd.conf files to a
> cn=config tree, though.

Sounds reasonable, though I haven't looked at the patch myself to understand
it, so hopefully this won't wait on me.

> > BTW, another wishlist item on my todo list is to revisit the use of
> > pthreads from within libldap_r; I've learned recently that many of the
> > pthreads functions are available as stubs in libc, which means libraries
> > can get away with not pulling in libpthread if these are the only
> > symbols they use, getting a performance boost in the process by not
> > having to go through the locking code when called from a non-threaded
> > app.  But last I looked at this, libldap_r had references to some
> > pthreads functions that were peculiarly non-library-ish.

> Bear in mind that libldap_r, as I understand it, exists basically for
> slapd and is primarily intended to meet slapd's needs.  It's only
> secondarily a client library, as I understand it.

Right, which is quite an unfortunate design decision... :)

FWIW, with 2.4.7 here are the symbols referenced from libldap_r that prevent
us from just using the libc stubs:

$ for sym in `nm -Du /tmp/libldap/usr/lib/libldap_r-2.4.so.2 \
              | awk '/pthread/ {print $NF}'`
do
	objdump -T /lib/libc.so.6 |grep -q "\.text.*$sym" || echo $sym
done
pthread_attr_setstacksize
pthread_create
pthread_getconcurrency
pthread_getspecific
pthread_join
pthread_key_create
pthread_key_delete
pthread_kill
pthread_mutex_trylock
pthread_rwlock_destroy
pthread_rwlock_init
pthread_rwlock_rdlock
pthread_rwlock_tryrdlock
pthread_rwlock_trywrlock
pthread_rwlock_unlock
pthread_rwlock_wrlock
pthread_setconcurrency
pthread_setspecific
$

So a fairly hefty list.  Still worth looking into, but not a short-term
project.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org