Re: MAIL_USE_FLOCK and Debian.

[Rob Browning]

Richard Stallman <address@hidden> writes:

> I think that is even more reason to control the decision at run time.
> Binaries are often moved from machine to machine, on a given platform.
> People will, for instance, install the Debian Emacs package on various
> Debian systems, some of which use liblockfile and some of which don't.

OK.  After thinking about it a bit more, I agree.  You're absolutely
right that a run-time setting would be better.  However, part of the
problem is that this policy is currently handled by the external
movemail program, so we'd have to figue out how to allow runtime
customization.  I would guess perhaps an /etc file, or command-line
arguments, though the latter probably wouldn't make it easy enough to
provide site-wide defaults...

> Do you agree?

I think so, but with regard to the implementation.  I think one of the
complicating factors is that the actual policies can be reasonably
complex, i.e. do you use flock and something else, flock first or
last, etc?

If the locking were handled by emacs rather than an external program,
then I would be tempted to suggest that we just publish the locking
primitives at the lisp level, and then provide a set of lisp functions
for various "standard" locking strategies along with a defvar
mail-locking-function.  Then you can pretty easily do whatever's
necessary, no matter how custom your requirements.

I guess if emacs' startup were lightweight enough, movemail could just
be turned in to an emacs script, but I suspect that might make some
contingencies unhappy, and might cause other complications I haven't
yet considered.

Two other related items for consideration.

  - I'm not sure if you know, but for Debian at least, the locking
    strategy embodied in liblockfile is also a well-defined algorithm,
    and policy doesn't actually require programs to use liblockfile
    (as far as I recall), but just requires them to follow the
    algorithm specified, so it would be possible to DTRT straight from
    emacs.  I believe there is already a native perl implementation,
    for example.

  - One thing that has been on my tentative to-do list for a while
    (and I may have mentioned before) is to consider the wisdom of
    installing movemail to /usr/bin so that everyone can use it.  This
    was originally suggested to me back when netscape (and others?)
    were installing their own movemail binaries to /usr/lib/....  I
    had originally considered suggesting movemail be a separate
    project (or part of something like coreutils), but realized that
    it probably wouldn't be acceptable for emacs to have the
    additional dependency.

> Would you like to implement it?

I'd certainly be willing to give it a try when we figure out what we
want.

-- 
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