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 :)
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