RFC: FreeBSD DB Port Reform

Matthias Andree ma at dt.e-technik.uni-dortmund.de
Thu Nov 6 07:52:06 PST 2003


Sergei Kolobov <sergei at freebsd.org> writes:

> How about this instead,:
>
> CPPFLAGS+=	-I${LOCALBASE}/include/db${BDB_VER}
> LDFLAGS+=	-L${LOCALBASE}/lib/db{BDB_VER}
> CONFIGURE_ENV+=	CPPFLAGS="${CPPFLAGS}" LDFLAGS="${LDFLAGS}"
>
> That way, third-party apps will link against -ldb, 
> and no patching will be required.

That will still require patches to a lot of ports (or their configure
scripts, respectively), many have magic to derive the library path from
the include path or assume they can get $COMMON_BERKELEYDB_LOCATION/bin
and $COMMON_BERKELEYDB_LOCATION/lib with the same prefix, --with-db= is
common.

These assumptions are met by existing Linux systems or manual BerkeleyDB
installs (that use the taunted /usr/local/BerkeleyDB.MAJOR.MINOR
layout), but we'll still break them with a lib/db*/libdb* layout.

We can't hope to simplify ports if we continue to break their build-time
assumptions, and I'd prefer to make such intrusive changes (that require
ports to be updated) in one single round and not today (to meet hier(7)) 

If hier(7) is so off-limits/intangible that we cannot leave a
/usr/local/$PORTNAME in addition to the usual stuff, we'll have to
continue patching the ports.

One way to avoid the BerkeleyDB.N.M directories altogether would be
either linking the then-current version, 4.1 at this time, to the
libdb-4.so and libdb.so files, and require that ports that use older
versions be patched, but I suspect we'll see a lot of trouble then from
people who assume that libdb-4 is libdb-4.0 rather than libdb-4.1. If
the path codes the version, this is less likely.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95


More information about the freebsd-ports mailing list