>>>>> "Jan" == Jan Harkes <jaharkes_at_cs.cmu.edu> 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.