apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: The case for apr-util-2.0
Date Thu, 06 Jun 2019 09:15:36 GMT
On 06 Jun 2019, at 10:38, Branko Čibej <brane@apache.org> wrote:

> $ 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)
> […]

That looks like a packaging bug. This is on CentOS7:

[minfrin@chandler ~]$ ldd /usr/lib64/libapr-1.so.0.6.3
	linux-vdso.so.1 =>  (0x00007ffee65c1000)
	libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f8d24138000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f8d23f30000)
	libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f8d23cf9000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8d23add000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f8d238d9000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f8d2350c000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8d24578000)
	libfreebl3.so => /lib64/libfreebl3.so (0x00007f8d23309000)

[minfrin@chandler ~]$ ldd /usr/lib64/libaprutil-1.so.0
	linux-vdso.so.1 =>  (0x00007ffd83171000)
	libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f2813501000)
	libapr-1.so.0 => /lib64/libapr-1.so.0 (0x00007f28132c6000)
	libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f28130c1000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f2812eb9000)
	libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f2812c82000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2812a66000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f2812862000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f2812495000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f2813962000)
	libfreebl3.so => /lib64/libfreebl3.so (0x00007f2812292000)

> 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.

+1.

Looking at the archeology, this problem was identified years ago, and each successive addition
has been properly modularised. What was needed was to go back and modularise the earliest
additions.

Regards,
Graham
—


Mime
View raw message