Quoting Fabrizio Polacco ([EMAIL PROTECTED]): > 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'm not sure there's justification for requiring a rewrite and continual maintenance of upstream patches just so debian can use liblockfile. If the upstream developers have a well-implemented, compatible locking mechanism, why should a debian maintainer disturb it? If a packaged mailer isn't compliant it might be worth writing in liblockfile support, but not if the package works. I also don't see the locking mechanism changing in the near future because it is the least common denominator across platforms in a networked environment. If linux nfs locks were ready for the mainstream and there were an easy way to select liblockfile's locking strategy, it might be worth reassessing; until it has definate benefits that cannot be acheived in any other fashion I think that mandating liblockfile is premature. -- Michael Stone, Sysadmin, ITRI PGP: key 1024/76556F95 from mit keyserver, [EMAIL PROTECTED] finger, or email with "Subject: get pgp key" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
