[Dovecot] dovecot tring to load sql modules

[Frank Cusack]

On August 13, 2006 10:15:30 PM +0200 Axel Thimm <Axel.Thimm at ATrpms.net> wrote:
> 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 :)

Yes I do.

- packaging is limited, you can't satisfy everyone if source code
  isn't modular enough
- you shouldn't be required to pull in deps from limited packaging
  capabilities

>> 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.

No, you didn't just explain why it is, you berated the OP for not
installing the dependencies.

>> 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,

Of course it is.  What if you could package multiple variants together
in one package, selectable at install time?

> 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

Of which LDAP, SQL, etc. seems one of those cases to me.

> 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.

And one of those reasons, quite valid, is for system dependency reasons.

> Manually dlopening libs breaks a lot of other technology like
> prelinking so it's usage is really scarce.

prelinking seems marginal to me, and in addition it's only done on Linux,
not the other platforms that dovecot supports.  But I accept that folks
may consider prelinking useful.

Another alternative is to create stub libraries for LDAP et al.  It would
even be neat to have some flag that tells the runtime linker to pretend
those libraries are there but return failure from all function calls,
however since you can't know the semantics of any library that seems
like asking too much.

-frank