Wrong install modulesdir for standalone ldb ?

[simo]

On Thu, 2010-11-18 at 15:25 +0100, Jelmer Vernooij wrote:
> On Thu, 2010-11-18 at 15:22 +0100, Jelmer Vernooij wrote:
> > On Thu, 2010-11-18 at 14:18 +0000, simo wrote:
> > > On Thu, 2010-11-18 at 14:59 +0100, Jelmer Vernooij wrote:
> > > > On Thu, 2010-11-18 at 13:33 +0000, simo wrote:
> > > > > When looking at the wscript files it seem like modulesdir is set to
> > > > > ${prefix}/modules/ldb by default. This resolves into /usr/modules/ldb.
> > > > > 
> > > > > This looks wrong and I remember we used to put modules in /usr/lib/ldb
> > > > > (which is FHS compliant). How do I fix this ? Is it enough to set the
> > > > > MODULESDIR variable in lib/ldb/wscript ?
> > > > We can't use /usr/lib/ldb anymore, since standalone ldb will now install
> > > > private libraries there. What about $prefix/ldb/modules ?
> > > If that expands to /usr/lib/ldb/modules I am ok with that.
> > Yep, it would.
> > 
> > > But what's the problem with having also private libraries there ?
> > 
> > > (Why are we having private libraries anyway ? All dependencies should be
> > > provided by the OS.)
> > We have a small library that provides command line option integration
> > and just contains some common code that is only used by the command-line
> > tools. It also has a dependency on popt, unlike the ldb library itself.
> > 
> > We don't have any API guarantees for this library, nor do we install any
> > headers for it. 
> The problem with also having private libraries in the modules directory
> is that we'll attempt to load them as modules - and fail, since they
> (rightly) don't have the requires symbols.

OK I just saw we try to load all modules in the directory at startup. I
am not sure why we do not simply load on demand, but that's another
discussion.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>