[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

db1/glibc debacle

For those of you wondering if this was intentional or not, consider it

For those that don't know, db1 has been gone from glibc proper since
after glibc 2.1.3. The only reason it was kept around was for backward
compatibility. Now it's time to dump it. By now I mean, here, early in
the sarge release cycle so we have time work out the details.

So here's a quick FAQ:

Q. Why not just leave it there?
A. db1 sources were ripped from old glibc. They were meant only to keep
   binary compatibility with potato and other 2.1.3 based dists. That's
   old news once sarge releases. Plus the sources aren't maintained by
   glibc upstream anymore, so it adds a bit of overhead to the glibc

   We used to have a db1.85 package set, which was supposed to help me
   rid this out of glibc, but someone decided it was obsolete, and
   removed the package. It needs to return if people really want db1.85
   natively, but using the db1.85/dbm compat layer in db4 is the best

Q. My package used to use db1 for dbm/ndbm support. How can I get that
A. This is where 99% of the packages that used libdb.so.2 are standing.
   Guess what? db2/db3/db4 all provide a compatible dbm interface by
   including db[234]/ndbm.h. I suggest going with db4, hard code "#include
   <db4/ndbm.h>" and -ldb4.

Q. You're a bastard and you should have given this more thought by
   checking for which packages used this.
A. Let's stop with the name calling. First off, it's near impossible
   (without unpacking everything and running objdump on it) to tell what
   uses libdb.so.2, since it is included with libc6. People should not
   have been using it to compile against in the first place, given all
   my warnings from the past about this (and all the problems we've
   already had with it trying to keep the compatibility around).

Q. So will you include the thing back in libc6 until we straighten all
   this out?
A. No. Keeping it is just a crutch so all you lazy bastards (sorry, I
   said no name calling didn't I?) can push it off some more. Let's just
   get everything fixed now.

Q. So what happens now?
A. Start getting packages recompiled against proper interfaces in db4,
   either by using the db1.85 or dbm compatibility layer, or straight
   out using db4 altogether. If you need help, email debian-glibc@l.d.o,
   and I'll help with whatever I can. I'm closing all the bugs against
   glibc for this, and reassigning back to packages that reassigned to

Q. You dip shit, I have to have this working on my mission critical
   applications and systems. You broke all my servers and my boss is
   threatening to fire me! Are you going to make up the difference in my
   salary now?!
A. Silly rabbit, unstable's for developers.

Debian     - http://www.debian.org/
Linux 1394 - http://linux1394.sourceforge.net/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Reply to: