On Tue, Jul 24, 2018 at 02:25:57PM +0200, Yann Ylavic wrote: > On Tue, Jul 24, 2018 at 11:43 AM, Graham Leggett <minf...@sharp.fm> wrote: > > Throughout APR we have a long established convention where > > “expensive” libraries are bound to APR through DSOs. All the SQL > > database drivers are like this, LDAP is like this, and so is crypto. > > I think this is a mistake (for crypto at least) and that it solves nothing. > As I already said, DSOs don't work better if the external lib is not > installed on the system in the first place (same dependency), and so > will libapr-util.
It's much worse than simply being pointless, pointless DSO abstractions make dependency management both more complex and more fragile for distributors. It is a total misfeature in both the crypto and LDAP cases. When I have a direct linkage (i.e. ELF DT_NEEDED tags): mod_ldap -> libaprldap.so -> libldap.so mod_whatever -> libapr.so -> libssl.so my (RPM/.deb/whatever) package manager can detect library dependencies and reflect that in package dependencies to ensure system consistency. When you stick a DSO abstraction in the middle that goes away, and now I have to track the dependencies manually (i.e. it's now fragile), even though I know that 100% of users of mod_ldap CAN ONLY and MUST use exactly the same libldap.so as if they had directly linked against -lldap. Rinse and repeat for libcrypto. This is obviously completely different to db-style APIs where users *actually care* because their runtime environments are completely different (pgsql/mysql/...), hence run-time selection (and configuration) is well matched by a DSO-based abstraction.
