On Tue, Jul 24, 2018 at 10:12 AM, Joe Orton <jor...@redhat.com> wrote:
> 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. > While this is a valid argument, as a distributor, you present the option of installing multiple DB providers, multiple crypto providers, etc. Due to the flexible nature of this API, they can pick, say, mariadb, and have only the single db provider loaded by libldl. Were APR to insist on 1:1 providers, the user could not switch to using postgresql, or could only do so by mapping both .so provider stacks into memory. Based on the way most modules are architected, they are completely abstract. The underlying mod_authn_dbd doesn't care about which provider is loaded. Only the libaprmodule-1.so does. The only fragile piece is aprldap-1.so, which completely exposes which ldap provider was chosen to the consuming application. This is why it was evicted from apr-2. If that is ever revisited and made entirely abstract, it would be welcome back into the fold. Yes, the manual tracking of dependency chains is a headache, but not insurmountable, and gives the users and packagers additional choices.
