Re: [Nmh-workers] slocal(1) and its dbm_open(3) Use.

[Ralph Corderoy]

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