On August 13, 2006 10:15:30 PM +0200 Axel Thimm <Axel.Thimm@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@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:
- 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