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.
** Changed in: man-db (Ubuntu)
Status: Confirmed => Triaged
** Changed in: man-db (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1001189
Title:
'man' command fails with lseek error opening cross-architecture
index.db file (on network share)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdbm/+bug/1001189/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
