[Dovecot] dovecot tring to load sql modules

[Axel Thimm]

On Sun, Aug 13, 2006 at 12:42:19PM -0700, Frank Cusack wrote:
> On August 13, 2006 11:44:41 AM +0200 Axel Thimm <Axel.Thimm at ATrpms.net> 
> wrote:
> >On Sun, Aug 13, 2006 at 11:10:50AM +0200, Jan Kundrát wrote:
> >>Dean Gibson (Mail Administrator) wrote:
> >>> Aug 12 17:09:28 athlon1 dovecot: auth(default): dovecot-auth: error
> >>> while loading shared libraries: libmysqlclient.so.10: cannot open shared
> >>> object file: No such file or directory
> >>> Aug 12 17:09:28 athlon1 dovecot: child 28705 (auth) returned error 127
> >>>
> >>> That's because I installed the RPM from atrpms.net using "--nodeps".
> >>> The RPM requires the above SQL library module, among others (inc.
> >>> postgresql and sqlite).  However:
> >>>
> >>> 1. Why do I need ANY SQL library???  I want PAM to do the authorization.
> >
> >So, where is the problem? Just don't use the mysql support. You won't
> >dump exim/sendmail/postfix because they have ldap support you don't
> >use, do you? The same is true for this package. It has a set of built
> >in features and you just activate them or not.
> 
> I agree with both sides!

No, you don't :)

> Packaging deps are limited by source code modularity.  E.g. if dovecot did
> authorization via plugins, there could be a dovecot-auth-sql rpm which
> would allow building against mysql but avoiding the runtime dependency
> where not needed.  Where such modularity does not exist, the builder
> needs to account for either the most common use or the broadest use, at
> the discretion of the packager or perhaps decided by policy.  So I'd say
> the rpm is appropriately packaged given dovecot constraints.  BTW, postfix
> LDAP support is modular (via a commonly available patch), so it can be
> built for LDAP but doesn't require it at runtime.
> 
> At the same time, I agree with the complaint about not pulling in deps
> that you don't want.  It seems rather thick headed to say "just add mysql,
> postgresql and sqlite, I say it's ok therefore what's the problem".

This is twisting my words, I explained why the matter is as it is, I
didn't relay anyone on blind trust.

> A better response would be, "packaging limitations require building
> against mysql et al. to support a larger userbase, if that doesn't
> suit you, build your own rpm, it's quite easy".

No, it's not packaging limitations, it's how dynamic linking works, so
if you like it's limitations in Linux/glibc. And we can't possibly
have all code in the world do conditionalized dlopening expecting to
possibly fail due to absent libs.

In the few cases where it makes sense the default dynamic linking
procedure is put out of place and done manually as you suggest. This
is mostly done when the additional functionality is built separately
from the main project, which is not the case here, or when there
should be no hard dependency between parts for various
reasons. Manually dlopening libs breaks a lot of other technology like
prelinking so it's usage is really scarce.

If you want a perfectly tailored system you can't use prebuilt
binaries, but need to build it yourself using configure/make/make
install or a distribution like gentoo. But you lose the testing
coverage as anyone has his own special version built with his own
special parameters and exhibits his own special bugs.

Enough said, we're talking about an issue that is not broken. ... :)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://dovecot.org/pipermail/dovecot/attachments/20060813/b964cf28/attachment.pgp