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 -- | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
