liblockfile0 and /var/spool/mail policy compliance

["Adam P. Harris" <apharris@onshore.com>]

This (trimmed) output from pkg-deps has me a little concerned about
the policy compliance from Section 4.5 of policy:

| All Debian MUAs and MTAs have to use the maillock and mailunlock
| functions provided by the liblockfile packages to lock and unlock mail
| boxes. These functions implement a NFS-safe locking mechanism. (It is
| ok if MUAs and MTAs don't link against liblockfile but use a
| compatible mechanism.  Please compare the mechanisms very carefully!)

root@burrito:/home/apharris# pkg-deptree liblockfile0
liblockfile0
  emacs20
  liblockfile-dev
  qpopper

Obvious packages which may be non-complaint:

 procmail
 deliver
 exim
 smail
 imap
 nmh
 fetchmail
 cucipop
 emacs19 (?)
 xemacs20 (?)

Am I just freaking or does this have the makings of a serious problem?

Note that testing this problem is very difficult.  One has to
identifiy a package with proper locking; then attempt to suspend the
MTA or MUA when it is grubbing around in the mail spool, then use the
complaint package to ensure it notices the lock.

Unless someone advises me against it, I'm going to look into what bugs 
need to be submitted, and submit them, possibly at 'important' level.

.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>


--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org