/var/tmp/portage/sys-libs/db-5.3.28-r2/work/db-5.3.28/lang/sql/sqlite # cat VERSION 3.7.6.2
546626 555040 578940 549258 574420
The only feasible solution I see here is to entirely disable the whole sql engine in db-5.3 and greater. See URL for my porpodes fix. Comments are welcome.
eh... that should read "proposed" in my previous comment.
It's NOT a true bundling, and this leads to a significant functionality loss. the --sql* options build an sqlite interface to a BDB database, including the CLI tool and the C/C++ bindings. Ubuntu ships these tools as well, and has shipped them since at least Precise: http://packages.ubuntu.com/zesty/db5.3-sql-util http://packages.ubuntu.com/precise/db5.1-sql-util
(In reply to Robin Johnson from comment #4) > It's NOT a true bundling, and this leads to a significant functionality loss. I don't see what "true bundling" means here. What we haven't yet discovered is which of the few security issues in dev-db/sqlite actually affect this interface to BDB. I have recorded a list of issues post-3.7.6.2 but that doesn't mean any of them affect sys-libs/db. The significant loss in functionality could be adequately covered with a USE flag.
(In reply to Robin Johnson from comment #4) > It's NOT a true bundling, and this leads to a significant functionality loss. > Can you please elaborate more on the fuctionality loss? I've tested my proposed change on four different systems (2x ~amd64, amd64, ~x86) and even recompiled all berkdb consumers against the non-sql version without any issues. If I'm not totally wrong this is a new feature of the db-5.x versions anyway so not providing the sql engine to at least stable users should make no difference compared to the db-4.8 version they had before.
(In reply to Lars Wendler (Polynomial-C) from comment #6) > (In reply to Robin Johnson from comment #4) > > It's NOT a true bundling, and this leads to a significant functionality loss. > > > > Can you please elaborate more on the fuctionality loss? > I've tested my proposed change on four different systems (2x ~amd64, amd64, > ~x86) and even recompiled all berkdb consumers against the non-sql version > without any issues. Find some code that uses the SQL engine, either by exec, or linking (in 5.x). > If I'm not totally wrong this is a new feature of the db-5.x versions anyway > so not providing the sql engine to at least stable users should make no > difference compared to the db-4.8 version they had before. The SQL engine was added in the 4.8 series, using bundled sqlite-3.5.9 sources, see db-4.8.30/db_sql/sqlite/parse.c, and results in the tool at /usr/bin/db4.8_sql. In 4.8, it's present only as the db${SLOT}_sql binary. In 5.x, it's ALSO available as a library: libdb_sql-${SLOT}.
We could add a USE=sql flag turned on by default, that way if someone knows they don't use the SQL features they can turn off the USE flag and not get the bundles library.
Merged
