On Mon, Oct 16, 2000 at 06:51:59PM +0900, Stephen J. Turnbull wrote:
> (1) It may be purely my own stupidity, but I had a symlink /vice ->
>     /playpen/Coda/vice, where my test server setup was.  Somewhere in
>     the install process, this got deleted, and a directory /vice was
>     made and initialized.  Needless to say, I had a lot of trouble
>     getting coda to find my existing data....
> 
>     I think this happened somewhere in the dpkg -i process, presumably
>     for coda-server_XXX.dpkg.  I'm not entirely sure, because I then
>     tried vice-setup (thinking maybe I needed to point the server at
>     the data for some reason), but I bailed out of that when it
>     threatened to reinitialize my RVM.  Anyway, we really don't want
>     to overwrite any existing stuff without a confirmation from the
>     admin.

This must have been vice-setup, because the coda-server debian packages
don't try to do any smart stuff in their postinstall scripts.

> (2) Urk:
> 
> tleepslib:/usr/local/Builds# ldd /usr/local/coda-test/sbin/auth2
>         librpc2.so.1 => /usr/lib/librpc2.so.1 (0x40021000)
>         liblwp.so.2 => /usr/lib/liblwp.so.2 (0x40046000)
> --->    libdb.so.2 => /lib/libdb.so.2 (0x4004f000)
>         libc.so.6 => /lib/libc.so.6 (0x4005d000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> 
> /usr/local/coda-test was configured and built by hand, from Coda
> current CVS circa Sept 22.  Note the libdb.so.2; the target is
> distributed as part of glibc and is evidently db 1.85 compatible.
> glibc was at 2.1.3 (Debian package revision 25 or so) at the time.
> 
> tleepslib:/usr/local/Builds# ldd /usr/sbin/auth2 
>         librpc2.so.1 => /usr/lib/librpc2.so.1 (0x40021000)
>         liblwp.so.2 => /usr/lib/liblwp.so.2 (0x40046000)
> --->    libdb2.so.2 => /usr/lib/libdb2.so.2 (0x4004f000)
>         libc.so.6 => /lib/libc.so.6 (0x40093000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> 
> The installation in /usr was built from debian/rules, Coda current CVS
> circa Oct 9, and /usr/lib/libdb2 is the Sleepycat Berkeley db v 2.77
> or so.  I probably upgraded glibc in the interim from 2.1.3 to 2.1.9x
> (I'm currently at 2.1.94, but the Coda configuration may have occurred
> at glibc-2.1.93; it's unlikely to have been under glibc 2.1.3).
> 
> Obviously the new auth2 was not pleased at my databases at all.
> 
> I'm not an autoconf wizard, I don't know what went wrong.

I don't know where debian's libdb1.85 compatible library went with the
recent glibc updates. In fact, the autoconf macro that is searching for
libdb1.85 complains loudly.

===
checking for dbopen in -ldb... yes
checking if -ldb is libdb 1.85... no
checking for dbopen in -ldb1... no
configure: warning: Found libdb2 instead of libdb 1.85. This uses
configure: warning: an incompatible disk file format and the programs
configure: warning: will not be able to read replicated shared databases.
<sleeping for a couple of seconds>
===

Jan