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

[Tom Gundersen]

On Sat, Jul 16, 2011 at 11:40 AM, Eric Bélanger <snowmaniscool at gmail.com> wrote:
> On Sat, Jul 16, 2011 at 4:09 AM, Jan de Groot <jan at jgc.homeip.net> wrote:
>> On Fri, 2011-07-15 at 20:48 -0400, Eric Bélanger wrote:
>>> Sure. I just did it in my WIP PKGBUILD to not forget.
>>>
>>> As no-one seems to know about the db moving part, I'm leaning into
>>> keeping  --localstatedir=/var/lib/openldap. I'll wait for a day or two
>>> in case someone wants to pipe in, unless you want me to go forward to
>>> get the new openladp package done for the tcp_wrappers removal.
>>
>> What db-moving part exactly? Doesn't the current package install the
>> database in /var/lib/openldap, and isn't that the logical place for it?
>>
>>
>
> The current package use the --localstatedir=/var/lib/openldap
> configure option. That does 2 things:
> - it creates a /var/lib/openldap/openldap-data/ directory where the db is stored
> - it creates a /var/lib/openldap/run/ directory where the unix ldapi
> socket will be located
>
> Although this is a reasonnable location for the db, you said in a
> comment on FS#21051 that /var/lib/openldap/run/ is a weird location
> and that /var/run would be better. If we want to change the location
> of the ldapi socket to /var/run, we'll need to use
> --localstatedir=/var as configure option. However, this will also
> change the expected location of the db to /var/openldap-data/ hence
> the db moving business.
>
> I guess it all boils down wether the weirdness of having the socket
> /var/lib/openldap/run/ is important enough to worth the hassle of the
> db moving.

My two cents:

It is indeed weird to have /var/lib/openldap/run, but I think it would
be weirder to have a /var/openldap-data (as far as I know packages
shouldn't really put stuff directly under var).

I suggest keeping this as it is, unless there is a way to only move
the run dir. In which case it should be moved to /run (rather than
/var/run).

About libexec:

libexecdir is usually meant to contain programs that should only be
run by other programs, and not by the user. So in principle it is
wrong to symlink from /usr/sbin to /usr/lib/. Maybe this is an
upstream bug?

-t