MAIL_USE_FLOCK and Debian.

MAIL_USE_FLOCK and Debian.

[Rob Browning]

On a Debian system, the setting of MAIL_USE_FLOCK in s/gnu-linux.h is
guaranteed to be wrong, so right now, Debian applies the patch below
and adds -DDEBIAN to CFLAGS in debian/rules.  Of course this fix isn't
appropriately general because it only works for people using
debian/rules to build Emacs packages.  So I'd like to figure out what
the "right" way to fix it would be.  The general rule is that on a
Debian system, you should only use liblockfile, nothing else.

Though I have patches that make sure that liblockfile is used and that
the location of the mail spool is detected correctly, we still need an
acceptable way to make sure that on a Debian system, MAIL_USE_FLOCK
isn't defined.

My patches also add support for dynamic detection and use of
USE_MAIL_SPOOL_DIRECTORY, CONF_MAIL_SPOOL_DIRECTORY,
CONF_MAIL_PROGRAM_NAME, MOVEMAIL_LOCK_LIBS, and the elisp-side
mail-spool-directory variable, though I'm not sure those changes, as
they stand, will necessarily be wanted upstream.  I discussed them
with Gerd some time back, but now I need to finish re-evaluating them
against current CVS, and to discuss them here to make sure they're
still desired.

Thanks

--- emacs21-21.2.orig/src/s/gnu-linux.h
+++ emacs21-21.2/src/s/gnu-linux.h
@@ -130,7 +130,14 @@
    programs.  I assume that most people are using newer mailers that
    have heard of flock.  Change this if you need to. */
 
-#define MAIL_USE_FLOCK
+/* On Debian/GNU/Linux systems, configure gets the right answers, and
+   that means *NOT* using flock.  Using flock is guaranteed to be the
+   wrong thing. See Debian Policy for details. */
+#ifdef DEBIAN
+#  undef MAIL_USE_FLOCK
+#else
+#  define MAIL_USE_FLOCK
+#endif

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

Re: MAIL_USE_FLOCK and Debian.

[Richard Stallman]

    On a Debian system, the setting of MAIL_USE_FLOCK in s/gnu-linux.h is
    guaranteed to be wrong, so right now, Debian applies the patch below
    and adds -DDEBIAN to CFLAGS in debian/rules.  Of course this fix isn't
    appropriately general because it only works for people using
    debian/rules to build Emacs packages.  So I'd like to figure out what
    the "right" way to fix it would be.  The general rule is that on a
    Debian system, you should only use liblockfile, nothing else.

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.

It would be good to identify them at run time.

Once we solve those problems, or decide on how to handle them, we can
easily override MAIL_USE_FLOCK in the cases where liblockfile should
be used.

Re: MAIL_USE_FLOCK and Debian.

[Rob Browning]

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

Re: MAIL_USE_FLOCK and Debian.

[Richard Stallman]

    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.

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.

A run-time configuration option is much more powerful and convenient.

So the code should compile support for using liblockfile whenever
liblockfile is defined, and should compile the other method as well
(whichever other method is used now), and the final choice would be
controlled by an environment variable or a file installed with Emacs.

It would be ok to extend this idea of run-time choice to the question
of whether to use flock.  The idea would be that there are three
possible methods, and the code for each one would be compiled whenever
the platform permits that, and the final choice would be made at run
time.

The variable MAIL_USE_FLOCK would then help control the default
setting for the run-time choice.


Do you agree?  Would you like to implement it?

Re: MAIL_USE_FLOCK and Debian.

[Rob Browning]

Richard Stallman <rms@gnu.org> 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

Re: MAIL_USE_FLOCK and Debian.

[Florian Weimer]

Rob Browning <rlb@defaultvalue.org> writes:

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

Maybe Emacs can offer access to the relevant system calls, so movemail
can be implemented in Lisp?  It can't be *that* hard...

Re: MAIL_USE_FLOCK and Debian.

[Rob Browning]

Florian Weimer <fw@deneb.enyo.de> writes:

> Maybe Emacs can offer access to the relevant system calls, so movemail
> can be implemented in Lisp?  It can't be *that* hard...

Sure.  I actually mentioned that later down, but with that approach,
there's a concern that you might upset any constituencies that really
want/need a standalone script.  I don't really have any measure of how
important a concern that is, but I have heard off and on of various
uses of movemail outside emacs.

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

Re: MAIL_USE_FLOCK and Debian.

[Florian Weimer]

Rob Browning <rlb@defaultvalue.org> writes:

> Sure.  I actually mentioned that later down,

Oops.  Shouldn't do so many things in parallel.

> but with that approach, there's a concern that you might upset any
> constituencies that really want/need a standalone script.  I don't
> really have any measure of how important a concern that is, but I
> have heard off and on of various uses of movemail outside emacs.

I'd guess that those people would be unhappy with *any* change in
movemail.  Maybe you can distribute it separately, unchanged?

Re: MAIL_USE_FLOCK and Debian.

[Alan Shutko]

Florian Weimer <fw@deneb.enyo.de> writes:

> Maybe Emacs can offer access to the relevant system calls, so movemail
> can be implemented in Lisp?  It can't be *that* hard...

movemail may need to be installed sgid on some systems, to have access
to the mail directory.  That won't work in lisp....

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Looking for a developer in St. Louis? http://web.springies.com/~ats/
"Hey, you berk! If the gods really cared do you think you'd be here?"

Re: MAIL_USE_FLOCK and Debian.

[Rob Browning]

Alan Shutko <ats@acm.org> writes:

> movemail may need to be installed sgid on some systems, to have access
> to the mail directory.  That won't work in lisp....

Ahh.  Thanks.  I'm surprised I wasn't thinking of that too, since I
have to set that up in the .deb postinst :>

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

Re: MAIL_USE_FLOCK and Debian.

[Richard Stallman]

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

A command line argument would let Emacs control the decision, but I
think that is undesirable.  People might use movemail from other
programs too.  We don't want to make it easy to use movemail wrong.
So movemail itself should figure out which way to do the job.

I think that the existence of some file somewhere in the file system
is the right way to control this.

    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?

I thought we had just three alternatives to consider: liblockfile, and
the two alternatives now implemented in movemail.   Now you seem to be
proposing additional alternatives.  I am not sure exactly what they are;
it sounds like you propose that movemail do more than one of those three.
Why do you propose that?

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

This does not affect the issue as far as I can see.

Re: MAIL_USE_FLOCK and Debian.

[Rob Browning]

Richard Stallman <rms@gnu.org> writes:

> I thought we had just three alternatives to consider: liblockfile,
> and the two alternatives now implemented in movemail.  Now you seem
> to be proposing additional alternatives.  I am not sure exactly what
> they are; it sounds like you propose that movemail do more than one
> of those three.  Why do you propose that?

If there are only three relevant strategies, then my comments are
irrelevant.  I just wasn't sure.  I wasn't sure that movemail offered
only 2 choices since I hadn't yet looked carefully enough to be
certain that there weren't some combinations #ifdefs that would allow
hybrid strategies like "flock then dotlock" or the reverse, on some
platforms, and I also didn't know if local admins might need (or if we
cared to try to support) custom policies.  If we were using elisp,
then we wouldn't have to decide, since customization would be easy,
but since we're probably not, we'll need to make sure we provide a
complete set of strategies.

However, if movemail only needs (and allows) two strategies normally,
and if adding support for liblockfile to that set then covers all the
relevant cases, then we should be OK.

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

Re: MAIL_USE_FLOCK and Debian.

[Rob Browning]

Florian Weimer <fw@deneb.enyo.de> writes:

> Maybe Emacs can offer access to the relevant system calls, so
> movemail can be implemented in Lisp?  It can't be *that* hard...

Oh, and although it looks like it's not going to matter, you're
definitely right about being able to implement movemail in Lisp if we
wanted to.  As an example, you might be able to implement the Debian
strategy (embodied in liblockfile) right now, without any changes to
Emacs, since it uses fairly unremarkable system calls.  From
lockfile_create(3):

  The algorithm that is used to create a lockfile in an atomic way,  even
  over NFS, is as follows:

  1      A unique file is created. In printf format, the name of the file
         is .lk%05d%x%s. The first argument (%05d) is the current process
         id. The second argument (%x) consists of the 4 minor bits of the
         value returned by time(2). The last argument is the system host-
         name.

  2      Then  the lockfile is created using link(2). The return value of
         link is ignored.

  3      Now the lockfile is stat()ed. If the stat fails, we go  to  step
         6.

  4      The stat value of the lockfile is compared with that of the tem-
         porary file. If they are the same, we have the lock. The  tempo-
         rary  file  is deleted and a value of 0 (success) is returned to
         the caller.

  5      A check is made to see if the existing lockfile is a valid  one.
         If it isn't valid, the stale lockfile is deleted.

  6      Before  retrying,  we sleep for n seconds. n is initially 5 sec-
         onds, but after every retry 5 extra seconds is  added  up  to  a
         maximum  of  60  seconds (an incremental backoff). Then we go to
         step 2 up to retries times.

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

Re: MAIL_USE_FLOCK and Debian.

[Richard Stallman]

    However, if movemail only needs (and allows) two strategies normally,
    and if adding support for liblockfile to that set then covers all the
    relevant cases, then we should be OK.

I think so.

Re: MAIL_USE_FLOCK and Debian.

[Rob Browning]

Richard Stallman <rms@gnu.org> writes:

>     However, if movemail only needs (and allows) two strategies normally,
>     and if adding support for liblockfile to that set then covers all the
>     relevant cases, then we should be OK.
>
> I think so.

It looks like the two existing movemail strategies are
MAIL_USE_SYSTEM_LOCK and MAIL_USE_MAILLOCK.  Presuming that's correct,
then we have to decide how to handle liblockfile.

In addition to the thread-safe, lower-level locking functions like
lockfile_create, liblockfile also provides maillock and touchlock
convenience functions, so if we're on a system that has both libmail
and liblockfile, which do we choose?  Unless we were going to do
something like runtime dynamic linking, we'll have to link against one
lib or the other at build time.  I don't really have any idea how
often this might be an issue.  The way the code is arranged in Debian,
liblockfile is always preferred if found...

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

Re: MAIL_USE_FLOCK and Debian.

[David Masterson]

>>>>> Rob Browning writes:

> It looks like the two existing movemail strategies are
> MAIL_USE_SYSTEM_LOCK and MAIL_USE_MAILLOCK.  Presuming that's
> correct, then we have to decide how to handle liblockfile.

> In addition to the thread-safe, lower-level locking functions like
> lockfile_create, liblockfile also provides maillock and touchlock
> convenience functions, so if we're on a system that has both libmail
> and liblockfile, which do we choose?  Unless we were going to do
> something like runtime dynamic linking, we'll have to link against
> one lib or the other at build time.  I don't really have any idea
> how often this might be an issue.  The way the code is arranged in
> Debian, liblockfile is always preferred if found...

Is there any reason that movemail has to be one executable?  Why not
make movemail into a wrapper around three programs that implement
(each implementing one strategy)?  That should simplify the build
process for each and, if any strategy doesn't make sense on a
particular O/S, the corresponding program can be rigged to return a
simple error for movemail to pass on.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: MAIL_USE_FLOCK and Debian.

[Richard Stallman]

    In addition to the thread-safe, lower-level locking functions like
    lockfile_create, liblockfile also provides maillock and touchlock
    convenience functions, so if we're on a system that has both libmail
    and liblockfile, which do we choose?  Unless we were going to do
    something like runtime dynamic linking, we'll have to link against one
    lib or the other at build time.

This seems to mean that we have to decide at build time.  If it has to
be decided at build time, the best thing to do is let configure choose
which library to use.

    Is there any reason that movemail has to be one executable?  Why not
    make movemail into a wrapper around three programs that implement
    (each implementing one strategy)?

I have nothing against this in principle, but it is full of pitfalls.
Many things can go wrong, and fixing them would require further
attention.  For instance, movemail needs to be able to find the other
executables, and that won't be trivial.  (We're talking about
installing movemail in /usr/bin.)

So we should avoid this unless it is absolutely necessary.

Re: MAIL_USE_FLOCK and Debian.

[Rob Browning]

Richard Stallman <rms@gnu.org> writes:

> This seems to mean that we have to decide at build time.  If it has to
> be decided at build time, the best thing to do is let configure choose
> which library to use.

Given the discussion so far, it seems like we could:

  - provide a run-time choice between the flock/lockf and maillock
    approaches on systems that support both, along with a
    configure-time choice between the liblockfile and libmail
    implementations of maillock when relevant.

  - provide a run-time choice between flock/lockf, maillock via
    libmail, and the liblockfile algorithm.  With this approach, we
    wouldn't use liblockfile itself (because its maillock would
    conflict with libmail's), just the code.  Though direct use of the
    code definitely has potential maintenance issues, at least as far
    as Debian policy is concerned, I believe that just implementing
    the algorithm is acceptable.  Of course, if we did use the code
    directly, we'd need copyright assignments.

  - build-time choice only -- similar to what we have now, but perhaps
    with an added --with-mail-locking=FOO which would require a
    specific approach.

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

Re: MAIL_USE_FLOCK and Debian.

[Richard Stallman]

    Given the discussion so far, it seems like we could:

      - provide a run-time choice between the flock/lockf and maillock
	approaches on systems that support both, along with a
	configure-time choice between the liblockfile and libmail
	implementations of maillock when relevant.

      - provide a run-time choice between flock/lockf, maillock via
	libmail, and the liblockfile algorithm.  With this approach, we
	wouldn't use liblockfile itself (because its maillock would
	conflict with libmail's), just the code.  Though direct use of the
	code definitely has potential maintenance issues, at least as far
	as Debian policy is concerned, I believe that just implementing
	the algorithm is acceptable.  Of course, if we did use the code
	directly, we'd need copyright assignments.

      - build-time choice only -- similar to what we have now, but perhaps
	with an added --with-mail-locking=FOO which would require a
	specific approach.

The second is a real pain.  Do you really want to go to that much
trouble?  If not, our choices are the first and the last.

Would you like to do the first one?

Re: MAIL_USE_FLOCK and Debian.

[Rob Browning]

Richard Stallman <rms@gnu.org> writes:

> The second is a real pain.  Do you really want to go to that much
> trouble?

Well I'd probably be willing if people thought that approach was
obviously the right choice, but if not, then I'd certainly be happier
doing something simpler :>

> Would you like to do the first one?

Sure.  That's fine with me.

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

Re: MAIL_USE_FLOCK and Debian.

[Michael Sperber [Mr. Preprocessor]]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

Richard>     Given the discussion so far, it seems like we could:

Richard>       - provide a run-time choice between the flock/lockf and maillock
Richard> 	approaches on systems that support both, along with a
Richard> 	configure-time choice between the liblockfile and libmail
Richard> 	implementations of maillock when relevant.

Richard>       - provide a run-time choice between flock/lockf, maillock via
Richard> 	libmail, and the liblockfile algorithm.  With this approach, we
Richard> 	wouldn't use liblockfile itself (because its maillock would
Richard> 	conflict with libmail's), just the code.  Though direct use of the
Richard> 	code definitely has potential maintenance issues, at least as far
Richard> 	as Debian policy is concerned, I believe that just implementing
Richard> 	the algorithm is acceptable.  Of course, if we did use the code
Richard> 	directly, we'd need copyright assignments.

Richard>       - build-time choice only -- similar to what we have now, but perhaps
Richard> 	with an added --with-mail-locking=FOO which would require a
Richard> 	specific approach.

Richard> The second is a real pain.  Do you really want to go to that much
Richard> trouble?  If not, our choices are the first and the last.

Richard> Would you like to do the first one?

XEmacs movemail does the first and third.  (It allows you to specify
a compile-time default and then override it at run time.)

I've offered cooperation on producing a shared movemail previously.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Re: MAIL_USE_FLOCK and Debian.

[Richard Stallman]

    Richard> Would you like to do the first one?

    XEmacs movemail does the first and third.  (It allows you to specify
    a compile-time default and then override it at run time.)

Once we have a run-time choice, it is trivial to add a way to set
the default at compile time.

    I've offered cooperation on producing a shared movemail previously.

Do you want to manage getting papers from all the contributors to the
XEmacs movemail?  If so, this would be practical.

Re: MAIL_USE_FLOCK and Debian.

[Michael Sperber [Mr. Preprocessor]]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

Richard> Do you want to manage getting papers from all the contributors to the
Richard> XEmacs movemail?  If so, this would be practical.

Sure.  There are only 3 besides myself who submitted anything >=10
lines, and one of them is Steve Baur, who's already signed papers, I
believe.  The others are Ben Wing and Andy Piper, and I'll get back to
you once I know more.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Re: MAIL_USE_FLOCK and Debian.

[Richard Stallman]

      The others are Ben Wing and Andy Piper, and I'll get back to
    you once I know more.

You will have trouble with Ben Wing, I think.  He may refuse, but even
if he is willing to cooperate, I think he was working for Sun, which
would mean we would need papers from Sun too.

But there is no harm in asking.

Would you be willing to redo his code if we cannot use it?

Re: MAIL_USE_FLOCK and Debian.

[Michael Sperber [Mr. Preprocessor]]

>>>>> "RMS" == Richard Stallman <rms@gnu.org> writes:

RMS>       The others are Ben Wing and Andy Piper, and I'll get back to
RMS>     you once I know more.

RMS> You will have trouble with Ben Wing, I think.  

No, he's already agreed.  I'm waiting for word from Andy Piper.

RMS> He may refuse, but even if he is willing to cooperate, I think he
RMS> was working for Sun, which would mean we would need papers from
RMS> Sun too.

No, this was after his stint with Sun.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Re: MAIL_USE_FLOCK and Debian.

[Richard Stallman]

    RMS> You will have trouble with Ben Wing, I think.  

    No, he's already agreed.

That is a pleasant surprise.