On Sat, Jul 16, 2011 at 11:40 AM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Sat, Jul 16, 2011 at 4:09 AM, Jan de Groot <jan@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