[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] More configuration stuff (acconfig.h)

From: Bill Wohler
Subject: Re: [Nmh-workers] More configuration stuff (acconfig.h)
Date: Sat, 07 Jan 2012 11:40:41 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Hi Nick,

nmh 1.4 is out. I hope you have some time soon to package it up.

Could you please comment on Ken's questions about the following
configuration items? Since I like the way you configure nmh on Debian,
I'd like to ensure that his suggestions are consistent with the way you
configure nmh. Thanks!

Ken Hornstein <address@hidden> writes:

> Alright, in preparation for finally cleaning up our suboptimal autoconf
> mess, I am tackling acconfig.h (a template which users can edit to
> change defaults).  My feeling is all of that should either be controlled
> by autoconf or we take a decision on whether or not to keep or remove
> that code.  Here is the list:
> LOCKDIR               - A directory to place lock files in if you're using
>                 DOT_LOCKING.  I've never been happy with nmh's use of
>                 dot locking, but do people actually use this?  It's
>                 easy enough to add the support for this to autoconf.
> DBMPWD                - The comment says "Define this if your passwords are
>                 stored in some type of distributed name service, such as
>                 NIS, or NIS+."  This only affects aliasbr.c ... and I
>                 guess what it does is controls whether or not names
>                 are cached from calls to getpwnam().  This has been
>                 turned on forever, I propose just removing the #ifdefs
>                 and making that code the default.
> DUMB          - Strangely, turning ON DUMB means you get an RFC 822
>                 parser.  If DUMB is NOT defined, you get MMDF and UUCP
>                 parsing as well.  I'm going to go out on a limb here and say
>                 we can safely remove MMDF & UUCP address parsing :-)
>                 Oh, on that note there's some code #ifdef'd as BANG
>                 which uses UUCP mailing syntax.  I'm just going to go
>                 ahead and remove that because I am 100% sure no one
>                 needs it.
> REALLYDUMB    - What this does is prevent adrsprintf() from appending a
>                 local hostname if a username doesn't have one.  You know,
>                 I really think this should be a run-time option instead.
>                 Anyone care if I make it so it is?  (The default can
>                 be off to match current behavior).
>               - Meh, at this point I'd say garbage collect this code,
>                 but I have no strong feelings.  Either we should keep it
>                 and remove the #ifdefs, or get rid of it entirely.
>                 Thoughts?
> RPATHS                - Construct Return-Path headers from "From " lines.
>                 I say keep it, since it's been around forever (a fair
>                 amount of code, actually).
> SLOCAL_MBOX   - If defined, use mbox format with slocal when saving to
>                 your mail spool, otherwise, use MMDF.  I say keep it
>                 and ditch MMDF support.
> MHRC          - Handle the ~ for filenames; this is a keeper, right?
> BUILTIN_FTP   - This was the only code I didn't add IPv6 code to.  It's
>                 turned on right now, but I have to question how useful it
>                 is (it's built-in ftp support for mhn).  I haven't seen
>                 MIME messages with external-body parts in forever, and
>                 even if we did get any I think this work should be forked
>                 off to an external ftp program or something like curl.
>                 Thoughts?  Actually, I wonder how many MUAs support
>                 MIME external-body anyway (okay, a quick Google shows
>                 that it's non-zero, but I suspect that a lot of it is
>                 done via http rather than ftp anyway).
> POPSERVICE    - Easy enough to autoconf it, but it's command-line selectable
>                 anyway.  Maybe simply hardcode the default?
> DEFAULT_FOLDER_MODE   - Leave these two as hardcoded defaults?
> LINK          - The same?
> ATTVIBUG      - Is this an issue anymore?
> --Ken
> _______________________________________________
> Nmh-workers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/nmh-workers

Bill Wohler <address@hidden> aka <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]