------- You are receiving this mail because: -------
You are the QA contact for the bug.
http://bugs.exim.org/show_bug.cgi?id=139
--- Comment #22 from David Woodhouse <dwmw2@???> 2008-05-14 17:09:38 ---
On Wed, 2008-05-14 at 16:18 +0100, Tony Finch wrote:
> I was thinking of situations where you want one build for a few
> different machines that use different sets of lookups. It saves time to
> only load the lookups that are required.
True. On the other hand, in such a manual installation surely you might
as well just delete the lookup modules you don't want, rather than
configuring Exim to load the ones you do?
> > When you say "creating a unified package", you mean a package such as
> > the existing distro packages, with all the lookups present -- except
> > that they're as modules, not built-in? That kind of defeats the object
> > of having them modular, surely?
>
> Not entirely. Exim could ship with the ldap lookup and would work even if
> the ldap libraries are not installed, and could support ldap when they
> are. (I'm imagining feeble package managers with weak dependency
> handling.)
Actually I think that works right now -- you can have the module
present, but it'll fail to load. Assuming your package manager lets you
install it without its dependency, of course :)
> > The reason I _don't_ like it is because it means you have to edit your
> > config when you (or your distro) switch to building with
> > dynamically-loaded modules.
>
> A valid point.
>
> I suppose I'm wondering if this feature can usefully be generalized to
> non-linux-packagey situations, but I'm happy to be convinced that there's
> no point.
I'm having trouble seeing the benefits of listing modules explicitly in
the config file, certainly. Although all we really need to overcome my
_objection_ to it is set the default behaviour to be loading all
available modules, but still add a config option which lets you list
them by name. That way, upgrades would still work fine without modifying
the config.
One other potential solution _might_ be to load lookup modules only on
demand -- so when Exim encounters '${lookup{...}FOO ...}' it'll go
looking for a FOO.so if it doesn't already recognise the lookup type in
question. Not entirely sure if that's easily extendable to all the ways
you can invoke lookups (like 'lsearch;...' etc.)
You'd also need to cope with the fact that certain modules provide more
than one type of lookup. A translation table or symbolic links could
achieve that, but makes it all seem a bit more Heath Robinson and a bit
less attractive...
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email