Pierre A. Humblet wrote: > Corinna Vinschen wrote: > >>On Thu, Jul 17, 2003 at 09:48:28PM -0400, Pierre A. Humblet wrote: >> >>>Bad news: >>>The new gdbm library can't open old gdbm files because >>>an internal structure has changed size.
[EMAIL PROTECTED]@[EMAIL PROTECTED] I did not realize that. I've withdrawn gdbm until we have a mechanism to convert "old" databases to "new". Does anybody know of a "gdbm to <platform independent>" database dumper (and reader!), so I don't have to write one myself? >>>Good news (at least for exim users): >>>Exim keeps no essential info in its db files. >>>All files in /var/spool/exim/db should be deleted when >>>installing the new gdbm. But that is certainly not true in general. Exim may be lucky -- and cvs (which uses gdbm) may also be lucky -- in the sense that the database files are intended to be ephemeral, or are backed by plaintext files (modules vs. modules.db) But not every gdbm user will be able to blow away their files. >> >>Wouldn't it make sense to add that to the postinstall script? This >>might get rid of a couple of "Exim 1.5.0 not work" questions on the ML. > Good idea. But how can I detect if it's the first time? > Also, people might jump from 4.20-1 to a future 4.X-Y > > Ah, the postinstall script could try to gdbm_open the files > and delete them on failure (e.g. using /bin/exim_dumpdb). > Strictly speaking it should be in the gdbm postinstall. Hell no. How would I know which files to delete? For every possible use of gdbm? This is first I've heard of gdbm being used by exim; I knew about perl and cvs. Tomorrow when package "foo" gets added to the cygwin distribution, *I* am required to update my gdbm package to take care of foo.db? Ain't happening. Should gcc search your entire disk for .o files, and delete them when gcc is upgraded? The old .o's may not be compatible with the new gcc, after all... > Not sure how far I want to go. The databases basically contain > optimization hints. Exim keeps going when it can't open them, simply > making a log entry. I need to think some more. We just need a conversion tool. As I said, gdbm is withdrawn. When I re-release a 64bit version, I'll bump the DLL version. That way, existing programs will continue to use the old cyggdbm. Plus, with some luck or help, I can write a program that dumps a database to an interchange format. executable #1 is linked to the old gdbm dll, and is used to write the database out to interchange format. executable #2 is linked to the new gdbm dll, and is used to read the interchange format in, and save out to a new gdbm file. It's also possible that executable #1 should be compiled on a stock cygwin-1.3.22 system... -- Charles Wilson cygwin at removespam cwilson dot fastmail dot fm
