Re: MAIL_USE_FLOCK and Debian.

[Rob Browning <rlb@defaultvalue.org>]

Richard Stallman <rms@gnu.org> writes:

> Would it be correct in all cases to use liblockfile whenever
> liblockfile is available?  If so, that would be pretty easy to do.
> If that is not so, can you identify the cases in which liblockfile
> is available but should not be used?  If that can't be identified,
> we are left with trying to identify the cases where it should be
> used.

If I understand the situation correctly, I'm not sure this is anything
that actually can be decided automatically.  The problem is that in
the final analysis, the policies with respect to locking may come down
to a local administrative decision.

In the limiting case, the "right policy" may not even be something you
can decide on a per-distribution basis.  For example, say that UT
Austin uses Debian (which they do).  In theory liblockfile would be
the right choice for Emacs, but hypothetically let's also imagine that
they have a heterogeneous collection of systems (RedHat, Debian,
Gentoo, etc. (and perhaps even other archs)), all sharing a giant NFS
mounted filesystem (at least in part).  Further, lets imagine that
rather than using the native packages for Emacs, they build one copy
of Emacs for all of these systems (where possible) and publish it over
NFS.  In that case, they may well know that flock (or something else)
*is* the right answer, even for the Debian systems, because they've
explicitly arranged for that to be true.  This of course assumes that
the right answer here is for all the systems to be using the same
locking strategy (see below for a counter-example).

The failure case would be for some of the systems to be using one
strategy and some of the systems to be using a different incompatible
strategy on the same shared mail spool (or shared home directories).
On Debian systems using liblockfile, NFS mounted spools are fine, but
they wouldn't be if other systems mounting the same spools weren't
using the same strategy.

Now we might just decide that in the above case, it would be
reasonable to expect the admins to just adjust the source code for
Emacs in order to respect their policies.  However, another
alternative might be for us to just make the locking policy a more
explicit choice.  We could do whatever checking we can in configure.in
to try and pick a reasonable default, but also allow a
--with-mail-locking={flock,liblockfile,...}  argument that would
insist on a particular strategy and cause configure to fail if the
request cannot be satisfied on the current system.

> It would be good to identify them at run time.

Since this is probably a "site-wide" policy issue, my initial
impression was that perhaps the locking strategy *should* be
hard-coded at compile time.  Though I guess if you were in a situation
where the Emacs binary was being shared across multiple systems
without non-shared mail spools such that the right answer was for
Emacs to use a system-specific locking strategy for the particular
system it was being launched on, rather than a common, site-wide
locking strategy, then run-time dectection would be more appropriate.

So it seems we have some tradeoffs here.  Overall, my current feeling
is that hard-coding the choice at compile time is probably going to be
the more useful choice most of the time, and although it's perhaps a
bit less flexible that run-time selection, choosing at compile-time
does make it extremely clear what's going to happen at run-time.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4