Re: liblockfile0 and /var/spool/mail policy compliance
Michael Stone <mstone@itri.loyola.edu> writes:
> 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.
Yes, but "works" here is not necessarily trivial to evaluate. Their
strategy may not be safe with respect to all the other packages on a
Debian system trying to lock the same file, especially when nfs may be
involved. It may be as difficult to review their code for Debian
locking compliance as it is to re-code it to link against liblockfile.
I'm happy for people to use something other than liblockfile, but I'm
not sure it's that much more effort to use it, and it's certainly
guaranteed to be consistent.
On a related note, I've sent a small bit of code to the liblockfile
maintainer that implements a little command line app that will handle
locking via liblockfile for scripts. You can run it to gain the lock,
run it again in the background with a different option to tell it
touch the lock every so often, kill the "toucher" when you're done,
and finally run it to remove the lock.
Something like
lockfile -l /some/file || exit 1
lockfile -t /some/file&
BADGER=$!
# Do something with /some/file here
kill $!
lockfile -u /some/file
--
Rob Browning <rlb@cs.utexas.edu>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: