Hi Ken, > > By all means make ndbm.h optional, it's pretty useless for a > > conforming program, but at the moment it doesn't seem to be causing > > ./configure trouble to porters. > > Well, look through the archives ... you'll find a number of people for > whom it causes problems
Yes, some of the older ones are because systems took time to conform to POSIX's ndbm.h. > (a lot of those problems seem to stem from some Linux distributions > having separate "devel" packages which contain the bits you need to > compile a program, and I guess the exact package you needed is never > obvious). Agreed, and that's not specific to ndbm.h. I wonder if ./MACHINES should give the common commands to find a package given a filename, and specify a key filename for each desired feature. Users could combine the two. $ pkgfile /usr/include/ndbm.h core/gdbm $ > No desire to do that; I've written Berkeley DB stuff for work and I > understand it's quirks, but again I don't really WANT to use it for > this tiny corner case. And I don't think Paul's Bloom-filter suggestion helps because that's just an optimisation given we still want a value for the key to say `Message-ID: ... already received on ...'. If ditching ndbm.h is particularly desirable then asking grep(1) to do the work on a flat file is going to be pretty quick, given most don't look at every byte. The short write(2)s to append would be atomic; no locking required. And it's just one more fork/execve in a long chain for delivering an email. When this suppression is reworked properly, it should probably store a `last seen' time(3) as well as the current `first seen' as pruning probably wants the former. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers