Re: liblockfile0 and /var/spool/mail policy compliance
On Mon, May 11, 1998 at 04:16:00AM -0300, Adam P. Harris wrote:
>
> 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!)
I noticed the last sentence and thought it was "wrong", but I was busy and had
no time to discuss it. Now I have it, so I jump on the thread and argue.
One of the strongest point in using an external library to supply a common
lock method is that, if you "force" all programs to use the external library,
then when a new and better "method" appears (for example because of changes
in the kernel) you only have to modify the library, and all programs using it
will use the new method without any danger for discrepancy.
I consider this as a "so strong" technical issue that I propose to change
policy to say (uppercase is mine and can be dropped):
| All Debian MUAs and MTAs MUST use the maillock and mailunlock
| functions provided by the liblockfile package to lock and unlock mail
| boxes. These functions implement a NFS-safe locking mechanism. (It is
| NOT ok if MUAs and MTAs don't link against liblockfile but use a
| compatible mechanism. The program MUST be dinamically linked to the
| liblockfile library and MUST use its routines.)
comments welcome!
fab
--
| fpolacco@icenet.fi fpolacco@debian.org fpolacco@pluto.linux.it
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E
> support the open-source initiative! http://www.opensource.org/
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: