[arch-dev-public] Moving openldap to core repo

[Eric Bélanger]

On Fri, Jul 8, 2011 at 2:52 PM, Eric Bélanger <snowmaniscool at gmail.com> wrote:
> Hi,
>
> I was looking into updating the orphaned libldap and openldap packages
> and couldn't help to notice that they should be in a splitted PKGBUILD
> instead of two seperate PKGBUILD.  It will remove duplicate work and
> probably make the PKGBUILD cleaner especially the build function which
> currently cd to subdirectories to only build what is needed for its
> specific package.  As openldap only depends on core packages, I don't
> see why it couldn't go in core.
>
> Any objections?
> Eric
>

As noone objected , I started work on a splitted PKGBUILD. I also
looked at two ldap bugs:
FS#14598 - [openldap] enable slapd overlays (slapo)
FS#21051 - [libldap] ldapi path never created by install

For FS#14598, I'll enable them as they just add libraries (plugins?)
to the package. It also adds libtool files which I'll keep as I have a
hunch they are needed like it's the case with the imagemagick modules.
That is unless someone tell me they are not needed as I don't use that
stuff. I'll also change the libexecdir from /usr/sbin to /usr/lib as
it seems strange to have a /usr/sbin/openldap/ directory with
libraries. With that change however, the slapd binary gets installed
in /usr/lib/ but I'll put a symlink in /usr/bin so everything will
work fine.

As for FS#21051, the current package use
--localstatedir=/var/lib/openldap instead of the more usual
--localstatedir=/var so we get weird directories like
/var/lib/openldap/run.  Changing this is easy, but the openldap daemon
use ${localstatedir}/openldap-data to store its database. This means
that we'll want a post-install message or front page news (or both?)
to inform users to move their openldap db to the new location.  The
problem here is that I'm not familiar with openldap or databases so I
don't know what these upgrade instructions should be. The only thing
that comes to my mind is the simple stop the daemon then move the db
manually with mv (maybe chmod/chown will be needed to keep the
perms/ownership) method. Would that work? Is there a better way like
an openldap tool or option to accomplish that in a more fool-proof
manner? I would rather keep the current location how irregular it is
than risk breaking something. I could post my current PKGBUILD and
even packages if anyone is interested into looking into this matter.

Eric