Re: [Nmh-workers] Locking - which to use?

[David Fellows]

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