[Pkg-openldap-devel] Post-etch OpenLDAP work

[Russ Allbery]

Hey all,

I want to throw this out to the whole group to get reactions, and also to
update you on where things stand for remerging the library and slapd
packages.

First, the work to make GnuTLS a fully supported SSL option is underway.
It will result in both new OpenLDAP and new GnuTLS releases, mostly
likely.  It should be complete by the lenny release, at which point my
hope is that we can provide library and slapd packages built against
GnuTLS for lenny.

I don't know whether it would be worth trying to figure out how to provide
packages built against OpenSSL at the same time or not.  My guess is that
the OpenSSL support will continue to be more mature for at least some
time, which means that large sites with heavy loads may wish to use it.
Given how interlinked everything is with the libraries, and given the
existance of LDAP NSS modules, it's difficult to get this right.

Second, once etch releases, we (Stanford University) are going to be
looking at deploying OpenLDAP on our production directory servers as a
Debian package.  Currently, due to compiler bugs in gcc and other
difficulties with the unofficial sarge amd64 release, Quanah has been
building gcc, OpenLDAP, and all its dependencies from source for our
production directory servers.  However, part of our standard operating
procedure is to have all installed software on all production servers be
packaged, so once etch is out and the base for amd64 is solid, we'll want
to change over.

Right now, Quanah's maintaining his own build, which is very heavily
tested under a huge production load.  We have multiple testing
environments here at Stanford to use to validate LDAP builds and a variety
of clients and stress tests that we throw at LDAP.  I would really like to
see the OpenLDAP slapd that Debian ships be the same or as close to the
same as possible as slapd that we're running in production here, with the
caveat that they'll always diverge around Debian release freezes and then
converge again afterwards.

So, the question is how best to get there from here.  We have a different
local patch set and more closely track OpenLDAP releases currently
(particularly since etch is in a freeze).  We also do some things that the
Debian package currently doesn't support but could (like using hoard as
the memory allocator, which isn't currently packaged for Debian; this is
normally done through LD_PRELOAD, so it can be an init script option).  We
also haven't cared about some things that Debian has to care about (FHS
layout, upgrading from old versions automatically, running as a non-root
user).

What I'd like to propose is that we branch the repository and that we
(mostly Quanah, but other people in my group may also contribute) develop
our packages on a branch.  This lets the people working on the initial cut
of packages not have to serve two masters and aim first at getting
something put together that we're willing to run in production and that
meets our local requirements.  Then, once that's done, we can look at the
differences between the branch and the trunk and figure out a merge
strategy, either fixing on the branch any additional Debian requirements
that we dropped by the wayside for local use and then blessing the branch
as the trunk or isolating the differences between the branch and the trunk
and applying them to the trunk.

How does that sound?  We have to do this work for internal reasons anyway,
and I want Debian to be able to benefit from it, but I think it will go
better if we isolate this work from the day-to-day bug fixing and user
support issues until we have an initial cut.  I expect that we'll have to
merge some trunk changes to the branch during this work, but I can help
with that.  Are there any problems that people see in this?

I'd like to get the opinions of everyone in the team who is following the
team.  I don't want to step on any toes or on any work that other people
were planning on doing.

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