On 13.8.2006, at 23.15, Axel Thimm wrote:
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.
Dovecot does support dynamically loading different SQL drivers as
plugins, and I don't really see much reason not to build the binary
packages that way. For some reason no-one has done that though. IIRC
Debian's reason was that they didn't want to bloat their package
count more than necessary.
http://wiki.dovecot.org/CompilingSource
Manually dlopening libs breaks a lot of other technology like prelinking so it's usage is really scarce.
In this case I don't think prelinking is all that useful. Dovecot's
not usually running in a desktop computer so boot up time isn't that
important. Dovecot-auth also is a long running process so the linking
has to be done only at startup.
imap-login and pop3-login would benefit the most from being
prelinked. Is this being done by anyone? :) I'm not actually sure how
it's even done, could/should I do it by default?