>>>>> "Jan" == Jan Harkes <[EMAIL PROTECTED]> writes:
Jan> Well it became virtually impossible to maintain code based on
Jan> libdb 1.85.
Yeah, we've been there before, that's how I guessed.
Thanks to Ivan who told me what I really needed to know: I have to
reinstall the old version of pdbtool. And thanks to Jan for
maintaining the debian/rules, because of course I can do that with
just dpkg -i ...!
Jan> The current sleepycat libdb is really overkill
Somewhat OT, but you (and others) might find this useful:
It's worse than that. Because of their targeting of the embedded
market, where many vendors use proprietary, non-ISO-conformant
compilers, they have huge amounts of cruft in the headers. They do
stuff like #undef const conditional on #ifdef __STDC__, which is a
non-conforming coding practice (conforming compilers are required to
#define __STDC__ 1, but some "ISO-wannabe" compilers do not #define
__STDC__ at all). There were incompatible interface changes between
4.0 and 4.1, and so on. :-( Unless you need Berkeley DB, it's just
not worth supporting it. (Not running down Sleepycat, by the way---
they were very helpful. It's just that users have to recognize that
their priorities are not tuned to stability for OSS projects that just
want Coda wants: a simple, rock-solid, lookup.)
Jan> and I've noticed that many/most opensource projects have
Jan> started to implement their own 'simple' databases. Samba has
Jan> tdb, enlightenment uses edb to make up for the loss of
Jan> libdb1.85.
I wonder why somebody doesn't just take up maintenance of libdb1.85.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
