[Pkg-cyrus-sasl2-debian-devel] Kicking off

[Henrique de Moraes Holschuh]

On Mon, 12 Dec 2005, Fabian Fagerholm wrote:
> Naturally, to be able to package Cyrus SASL, we need to be able to build
> it in the first place. Here's what I've done, to build it from upstream
> sources (cyrus-sasl-2.1.22, openldap-2.2.26):

I have not looked, maybe you're already doing this, but let me call
attention to some *key* points when packaging anything Cyrus:

1. Override everything (and I mean *everything*) CMU includes that we
   already have in Debian.  I mean libraries here.  Typically gettext
   and et (comerr-dev).  Don't trust blindly the build system to be
   correct, rm -rf et/ has been in Cyrus 2.1 debian/rules clean for a 
   loooong time now :-)

2. Don't even think twice about it: deploy autotools-dev, remove
   *every* autotools, libtool and gettext (now autopoint) generated file
   that comes from upstream, and re-generate this from Debian packaged
   tools.

3. Pay extreme attention to the versioned symbols and SASL module ABI,
   plus the usual library ABI changes.

SASL must version *all* of its symbols, and it must be *fully reentrant*.

We have to patch it to make sure it has _no_ global state that can make it
misbehave if used in different modes by several parts of a linked
application (client on libc/nss, server and client on main app, server or
client on libraries).  That also means we have to patch it to make sure it
can be used at the same time in server and client mode.

I think Debian SASL has all of that already, but every time we screw the
above up, any system using something in nsswitch that links to SASL (say,
OpenLDAP) will cause severe meltdowns especially in SASL servers (cyrus,
postfix...).

>       * Which libdb should we link with? My suggestion is to keep with
>         whatever is used with the cyrus-imapd packages.

We will have to either use DB 4.3 (it has versioned symbols), or we have to
get DB 4.2 to version their symbols too (and *fork* it if it doesn't).

*Every* library SASL links to must be fully versioned if we will ever have
more than one of them active in Debian in a given time.

That said, I'd prefer a versioned DB 4.2, it is far more stable than DB 4.3.

Let's pester people up on pkg-db-devel at lists.alioth.debian.org about the
issue.  I will cross-post a question to them soon.

>       * Which Kerberos implementation should we link with? (Note:
>         postgres links with MIT?)

Ask the kerberos maintainers. The right thing to do (I think) is to link to
*both* producing different packages, last time I checked, only gssapi
modules are affected, we can package them separately.  Do recheck this,
please.

>       * Which MySQL library should we link with?

Debian's default one.  Ask mysql maintainers which one...  If needed, we can
link to all of them, and package modules separately (see kerberos).

>       * Which SQLite library should we link with?

See above ;-)

>       * Are there other alternatives besides linking with libldap2-dev?
>         There has to be, otherwise cyrus-sasl2 won't build. OpenLDAP 2.2
>         must be used.

No idea.

>       * Update libtool and auto* stuff -- at build-time?

**YES**.  Either at build time or at repository checkout time, but you
*must* do it.

>       * Cyrus SASL must be linked against libldap which in turn needs
>         SASL. To get around this, a non-LDAP SASL must first be built.
>         Then, OpenLDAP can be built using that non-LDAP SASL. Finally, a
>         new SASL can be built with LDAP support using the OpenLDAP that
>         was built using the non-LDAP SASL. Messy. I don't know exactly
>         how to handle this in the packaging, but I guess we'll have to
>         bootstrap the package into the archive by building the first
>         version of the package manually. Wiser people should comment
>         here.

I'd ask this in d-devel.  What do the current packages do (or do they do
nothing because they don't support openldap?)

>       * Please document stuff. There's some fairly deep voodoo required
[...]

Sure.  Add a debian/README.Source there, and let's write down everything we
do that is non-obvious.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh