On Sun, 5 Feb 2012 15:38:08 -0800
Lyndon Nerenberg wrote -
>
> On 2012-02-05, at 3:13 PM, David Fellows wrote:
>
> > I find I have no need for /bin/mail so I have not installed a package =
> that
> > provides it. nmh, fetchmail, and ssmtp are sufficient for my needs.
>
> Okay, now you're just being a pain in the ass. So you didn't install =
> binmail. This changes the API how? Stop wasting our time with this =
> drivel.=
Perhaps I did not make myself clear. Let me try again.
I believe this thread is about configuration/build choices, not the API.
The proposal was that the configuration and/or build and/or runtime determine
in an as yet unspecified manner the locking mechansim in use for access to
the system maildir and use it -- and that this behaviour be "unalterable".
My request is that if this process in unable to determine what this mechanism
is that it not fail to configure, build or run as the case may be, but do
something reasonable.
In particular, if there is no other program doing locking on maildir, nmh
can pick its own locking mechanism. Alternatively, leave in an override option.
I guess the logic would be something like:
if there are ONE OR MORE programs locking system maildir
then
Assume they are playing nicely
if determine their locking mechanism
then
use it
else
fail and seek human intervention
fi
else
there is nobody here but me
use a suitable locking mechanism, probably the same as for internal
locking
fi
What I am asking for is the first test and last else clause.
I admit I have no idea what the tests would be.
Gentoo does have a basemail package that ensures that
/var/spool/mail exists with what Gentoo believes are the correct
properties. so testing for the presence or absence of
/var/spool/mail doesn't help me.
Dave F
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
