[Pkg-openldap-devel] Proposed layout for svn.

[Russ Allbery]

Steve Langasek <vorlon at debian.org> writes:

> Well, I suppose that at this point we're looking at a full database dump
> & reload anyway for 2.3.39 -> 2.4.7, right?  And that's probably going
> to be the easiest way for us to handle the db4.2->db4.6 transition as
> well, given that there's already packaging infrastructure for this
> method and not for the "BDB upgrade" method?

Yup, exactly.

> 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.

> 2) make a decision on whether db4.6 is ready for switching now, or if we
>    should be waiting for resolution of the NPTL yield() issue described in
>    #421946 before making the jump

Quanah, could you comment on this?  How important is this change?

> 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.

> 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.

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.

> And once uploaded, since I'm deliberately taking over the libldap2-dev
> package name, getting all the reverse-deps migrated off of libldap2
> should be a simple matter of binNMUs (and maybe some bugfixes).

I'm guessing there will be at least some API changes that will require
changes in the code of other packages, but hopefully that will be minimal.

> 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.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>