Summary says it all... Can we update to replace db-1 and db-2 and db-3 all be handled by _just_ db-4 for 1.4_final, gentlemen? Your thoughts and insights please.
I don't see why not. Note that there are packages that a) *think* they require some other DB, but don't b) really do require some other DB
is there a list, or a way to find out which? or is this going to be brute-force?
jrray will handle this :)
apache-1.3.27-r1.ebuild needed a couple touch-ups to build with db-4.1.24: src_compile() { local myconf mycflags - mycflags="${CFLAGS}" + mycflags="${CFLAGS} -I/usr/include/gdbm" The way apache ultimately decides to include libgdbm bypasses the code from the redhat patch that adds /usr/include/gdbm to the includes, so I just add it in the ebuild. Then, mod_auth_db.c doesn't compile because a function call is missing an arg. #if defined(DB3) || defined(DB4) if ( db_create(&f, NULL, 0) != 0 - || f->open(f, auth_dbpwfile, NULL, DB_HASH, DB_RDONLY, 0664) != 0) { + || f->open(f, NULL, auth_dbpwfile, NULL, DB_HASH, DB_RDONLY, 0664) != 0) { I made a new 'apache-1.3.27-gentoo.diff.bz2' patch that incorporates everything from the previous patch plus this change.
mysql-4.0.1_alpha.ebuild The configure script is hard coded to look for a couple specific db 3.2 versions (with a comment that suggests the authors expect that db version to be current for a while). After changing the scripts to accept db-4, I ran into an unrelated compilation problem: make[1]: Entering directory `/var/tmp/portage/mysql-4.0.1_alpha/work/mysql-4.0.1-alpha/sql' c++ -DMYSQL_SERVER -DDEFAULT_MYSQL_HOME="\"/usr/local\"" -DDATADIR="\"/usr/local/var\"" -DSHAREDIR="\"/usr/local/share/mysql\"" -DHAVE_CONFIG_H -I/usr/include -I../innobase/include -I./../include -I./../regex -I. -I../include -I. -O3 -DDBUG_OFF -fno-implicit-templates -fno-exceptions -fno-rtti -c mysqld.cc cc1plus: warning: changing search order for system directory "/usr/include" cc1plus: warning: as it has already been specified as a non-system directory mysqld.cc: In function `int main(int, char**)': mysqld.cc:1815: `regex_init' undeclared (first use this function) mysqld.cc:1815: (Each undeclared identifier is reported only once for each function it appears in.) make[1]: *** [mysqld.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/mysql-4.0.1_alpha/work/mysql-4.0.1-alpha/sql' make: *** [all-recursive] Error 1 It is pulling in /usr/include/regex.h (from glibc) and regex_init isn't defined in there. There is a regex library that comes with mysql, but when I changed mysqld.cc to include it ('../regex/regex.h'), I got gobs of errors. This package is masked, so I'm not sure what the strategy for it should be. Obviously I can't test to see if db4 works if I can't get it to compile.
Regarding mysql -- take a gander at the other ebuild for 3.x and see how they use the db version that comes with mysql -- it's been extensively modified from the stock db version -- mysql should *not* use the system db.
Seems kdesdk wants db-2 to build a plugin for kbabel. Right now it doesn't build it because configure checks for db-2, which we don't have (not even an ebuild?) and never noticed the failed configure check until now. So this is a case of adding functionality not fixing it. Both the configure test and the actual source call db_open() which isn't defined in the headers from db-1 and db-3. I don't know anything about db; where do I go from here? Would db-4 have db_open(), and is it safe to emerge (ie won't clobber things)?
Dan, welcome to the joy of db. The db_open call came and went with the 2.* versions of the API, and we don't have a 2.* flavor ebuild (I don't know why). The software in question, any software really, can be ported to a newer version of the database with a minimal patch, see http://www.sleepycat.com/docs/ref/upgrade.3.0/open.html for an example. The open call even varies a little between 3.* and 4.*. Since this bug is about making everything compatible with 4.*, you need to toss in an extra NULL argument, which is described here: http://www.sleepycat.com/docs/ref/upgrade.4.1/fop.html But if you're trying to unmask this you'll want to make it compatible with 3.x for the time being, I suppose.
sending to you, grant
Okay, you can now see the status at http://www.gentoo.org/~pauldv Yesterday I built a gentoo system using only db4 for the default system. I managed to get everything to build, but there were a few glitches: * gdbm links against db1 if "berkdb" in USE. It will link against db4 just fine. * pam will not build pam_userdb w/o db1 (the ebuild has a db3 DEPEND, but ldd shows db1 used) * perl needs a special db patch to be built (perl-5.8.0-r11.ebuild) I think getting those packages fixed before 1.4 is doable. I'm not sure about the whole distro. At the moment we have a situation where db3 and db4 can live side-by-side, so the impetus is no longer so great. Paul, rac, comments?
According to pauldv's testing, the DB_File version in the 5.8.0 core is OK with db 4.0, just not 4.1. The 5.8.0-r11 fix will be needed for db 4.1. Theoretically, we could get away with just relaxing the dep in the 5.8.0-r10 ebuild, I think. However, I'd like to go ahead with -r11, if no problems are found with it, as it will give us forward compatibility with the next revision of db coming down the pipe.
I would like to add that the python versions that are currently in portage do not build with db4 when both are installed, but use db3. I do not know about the case when only db4 is installed.
Reassigning to Paul, since db4 stuff is his baby.
this is obsolete, and not sensible. some packages link against specific versions of db on purpose (and there are also those packages that work with nearly any version).
