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

[Steve Langasek]

On Tue, Dec 11, 2007 at 04:24:08PM -0800, Quanah Gibson-Mount wrote:

> > No, none, however be aware that databases will require a dump and restore
> > between 2.4.6 and 2.4.7.

> Actually, they only need to be re-indexed.  And technically, only 
> attributes that use integer syntax need reindexing (in 2.4, you can specify 
> only particular attributes for indexing, a great improvement. :P )

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?

On Fri, Dec 14, 2007 at 10:23:27AM -0800, Quanah Gibson-Mount wrote:
>> For packaging reasons, sure 2.4.6 is fine. 2.4.7 should be out sometime
>> in  the next few days.

> 2.4.7 was released yesterday, so if packaging work hasn't begun yet, I'd 
> start with it. ;)

Right, as the flurry of commit messages from yesterday show, this is on its
way now.  I have a package in trunk that builds successfully, and at a
macroscopic level puts everything where it belongs.  So here's what I know
of that's remaining on the TODO list before we can upload to unstable:

1) get symbol versioning support into the package for libldap, so that we
   cut down the segfaulting with partial upgrades
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
3) proper upgrade support for 2.3.39->2.4.7 databases
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)

I'm taking responsibility for 1 and 3, looking for support from the rest of
you guys on 2 and 6, and expect 4 and 5 to be a communal effort.

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

If anyone knows that I've missed something here, please comment.

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.

Cheers,
-- 
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