db1/glibc debacle
For those of you wondering if this was intentional or not, consider it
intentional.
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
maint.
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
way.
Q. My package used to use db1 for dbm/ndbm support. How can I get that
now?
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
glibc.
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: