Some library and packaging advice please?

[Neil Joseph Schelly]

I'm trying to build a Kolab server for use at work and running into some 
problems.  I'm hoping someone here has some expertise that they can offer to 
help me resolve some issues I'm having, especially if you've used Kolab or 
other software packages distributed with OpenPKG before.

The environment I'm working in is Debian, but the versions of Kolab in Debian 
(both etch/stable and lenny/testing) are older than I want to use, in order 
to have Kolab work well with the Horde webmail/calendaring applications.  So 
the "source" distribution from Kolab is what I'm using.  The way they package 
things is with a tool called OpenPKG, which essentially means that an 
application (kolab), and all supporting applications (cyrus, openldap, 
apache), and all supporting libraries (tons of the usual) are packaged in RPM 
files.  Those RPM files are distributed with a script to setup a root folder 
(/kolab) and compile/install all those source RPMs into it.  Everything lives 
in this neat little bubble with libraries all statically compiled into the 
binaries, never leaving the confines of /kolab.  To say the least, I'm not a 
fan of this bubble approach.

For all our servers, we have LDAP logins enabled for SSH logins, monitoring 
logins, etc.  I don't expect that this new mail server should be any 
different, but if I enable LDAP logins on the system, many binaries segfault.

Here's my explanation of what's happening.  When you start a process, glibc is 
loaded as part of that process. glibc can also bring in other auxiliary 
libraries, as needed.  In particular, any libraries used for NSS 
(libnss_ldap.so, for example) are loaded also to give the process it's 
identify.  As a result of that, libldap_r.so is also loaded, because it's 
required to make use of libnss_ldap to make use of getting local user/group 
information from LDAP.  When the process that is starting is a binary in 
the /kolab bubble, it has libldap_r.a compiled into it statically, albeit a 
slightly different version.  This causes a duplication of all the library 
functions in the run-time process now.

I've been trying to convince OpenPKG with a dummy package not to use the 
Kolab-distributed OpenLDAP sources, but to use the libraries that come with 
Debian to no avail.  The dependencies spider out from there to things like 
sasl, gnutls, gcrypt, 

Has anyone tackled problems like this before?  I'm about at my wit's end with 
this.
-N