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