This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
From: Andreas Jaeger <aj@suse.de> Date: 05 Jan 2000 10:07:56 +0100 I'm adding a first patch for db30 support. I also need to update makedb.c but like to hear your comments before I continue. Unfortunately, the DB error return codes (DB_KEYEMPTY and DB_NOTFOUND) were also changed in DB 3.X. Fortunately, the release notes for 3.0.55 say: The Berkeley DB interfaces have been reworked in the 3.0.55 release for two reasons. The goals were as follows: to make the Berkeley DB structures opaque so future releases of Berkeley DB can be binary compatible with each other, ... so the interfaces may stabilize, and adding support for DB 3.X seems to be a good move! However, I'm not sure whether having a fixed list of library names is such a good idea. The format of the databases on disk depens in the DB version. A hard-coded list means that if the DB library is upgraded, the nss_db module might stop working. This can be fixed by regenerating the databases, but what if the someone uses a different LD_LIBRARY_PATH from time to time, or worse, has applications with different RPATH's? I think we should allow the user to specify the path of the DB library in a configuration file to make sure there will be no nasty surprises. Mark
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |