Re: liblockfile0 and /var/spool/mail policy compliance
Quoting Fabrizio Polacco (fpolacco@icenet.fi):
> 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,
mstone@itri.loyola.edu finger, or email with "Subject: get pgp key"
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: