Comment 25 for bug 1001189

Not really. I don't want man-db to be in the business of knowing what's local vs. not, and I very much want to preserve the property of having one database per MANDB_MAP entry. I think it would actually be much more complicated to attempt to unwind that - for instance there'd be interesting effects on localisation.

Having gdbm detect this is the right answer here, and if it does so then I think everything in man-db should just work, gracefully falling back to non-database-backed operations. So gdbm 1.9.1 sounds like the right answer; but of course that will do nothing as such to address the specific case here, because gdbm 1.9.1 can still read older database files (excellent for most other purposes) and so we're still going to crash on trying to read a database file created on a 64-bit 10.04 system on a 32-bit system. I therefore think we still need to figure out some more graceful handling of this in man-db.

The awkward bit is that the error goes through _gdbm_fatal, which does have a mechanism for the application to provide a different function to print the error message, but calls exit(1) either way. I can think of three ways to deal with this:

 1) Poke around in the database file ourselves, trying to guess whether the "dir" offset looks plausible given the file size.
 2) Fork to do an initial test open of the database.
 3) Pass in a fatal error handling function that uses longjmp to avoid the exit(1) call in the library.

1) is fragile and foul on general principles. 2) has performance problems at scale, perhaps not a problem in practice but I'd prefer to avoid it. I think 3) is the most practical, although it will take some fiddling to get it right.