On 06.06.2019 09:29, Nick Kew wrote: >> On 6 Jun 2019, at 06:07, Mladen Turk <mt...@apache.org> wrote: >> >> I remember the days when apr was operating system abstraction layer, >> and apr-util was the bunch of platform independent code where one >> could eventually decide which key/value dbm (beside provided sdbm) >> and bundled subset of expat. And then there was apr-iconv > You said it yourself. Dependencies already in apr-dbm! > >> When asking why can't we put some of the cool apr-util stuff >> like buckets, date, queue, etc ... to apr, there was a strong >> dislike "because that's not OS abstraction stuff" > An "insider" view. For the outside world, the apr/apu split achieved > very little beyond mild confusion. The whole package is, after all, > still pretty small in the global scheme of things.
$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.2 LTS Release: 18.04 Codename: bionic $ apt-cache search aprutil libaprutil1 - Apache Portable Runtime Utility Library libaprutil1-dbd-sqlite3 - Apache Portable Runtime Utility Library - SQLite3 Driver libaprutil1-dbg - Apache Portable Runtime Utility Library - Debugging Symbols libaprutil1-dev - Apache Portable Runtime Utility Library - Development Headers libaprutil1-ldap - Apache Portable Runtime Utility Library - LDAP Driver libaprutil1-dbd-mysql - Apache Portable Runtime Utility Library - MySQL Driver libaprutil1-dbd-odbc - Apache Portable Runtime Utility Library - ODBC Driver libaprutil1-dbd-pgsql - Apache Portable Runtime Utility Library - PostgreSQL Driver $ apt-cache show libaprutil1 Package: libaprutil1 [...] Depends: libapr1 (>= 1.6.2), libc6 (>= 2.25), libdb5.3, libexpat1 (>= 2.0.1), libgdbm5 (>= 1.14), libssl1.1 (>= 1.1.0) [...] I specifically object to libexpat, libssl, libdb and libgdm being on this dependency list ... the latter two are just bloat, but the former two create all sorts of problems for any project that happens to use either of them directly. So yes, it would be nice to abstract such dependencies out of the core APR 2.0 as that might (maybe, possibly) convince downstream packagers to think a bit more carefully about packaging optional dependencies. > Having said that, reversing the split from where we are now could > just be more confusion. Ho, hum. What, confusion for everyone who uses APR 2.0 today? I feel a distinct lack of interest. :) [...] > I think you're arguing for fully-baked apr modules, yesno? I'm not sure what you mean by "fully baked." IMO it would be good enough if dependencies such as dbd and crypto (and possibly xlate) could be loaded at APR initialisation time but never unloaded. -- Brane
