[blfs-support] New dovecot page: '--with-...' specs.

akhiezer lfs65 at cruziero.com
Thu Nov 14 10:12:46 PST 2013

> Date: Thu, 14 Nov 2013 16:08:48 +0000
> From: Ken Moffat <zarniwhoop at ntlworld.com>
> To: BLFS Support List <blfs-support at linuxfromscratch.org>
> Subject: Re: [blfs-support] New dovecot page: '--with-...' specs.
> On Thu, Nov 14, 2013 at 11:40:42AM +0000, akhiezer wrote:
> > 
> > Hi,
> > 
> > 
> > On the new dovecot page (
> > http://www.linuxfromscratch.org/blfs/view/svn/server/dovecot.html), the section 
> > 'Command Explanations' lists the five options '--with-ldap' et seq: yet none of 
> > them actually appear in the commands. I've noticed a similar thing in several 
> > places in blfs74 book.
> > 
> > 
> > Apols if have missed an earlier discussion on that, but: is this an error in 
> > rendering; or is it kindof that those '--with-ldap' &c options are really meant 
> > as a sort-of subsection concerning other main parameters that the user might 
> > want to consider? But in any case, them appearing as-is just looks like it's an 
> > error (e.g. "has a chunk of text been lopped off the 'configure ...' commmand?"), 
> > and one repeated elsewhere in the book.
> > 
>  They are tagged as <option> in the xml, instead of <command>, and
> different browsers may render them differently.
>  In firefox, the command --disable-static shows in italic monospace,
> although the directory class overrides that to what I suppose is bold
> monospace for the moduledir.
>  The options are rendered in normal weight monospace.
>  Yeah, I would prefer italic for options but I'm not touching that
> stuff (the xml itself) with the proverbial barge-pole.

Yes, but it could really do with a brief sub-title or one-liner indicating the 
change in context; perhaps auto-inserted by rendering rules.

As-is, it just looks like two lists spliced together rather oddly, and 
seemingly having a mismatch with what is in the displayed 'configure ...' 

Perhaps something like - taking onboard your clarification below re defaults, 
and given that there's often more options besides: "Some users may want to use 
some of the following 'configure' options, that are amongst those that are not 
enabled by default."; or, "The following 'configure' options are among those 
not set by default, and that may be of particular interest to some users."

Some of the blfs74 pages do contain a little snippet of text pointing the user 
to further 'configure' options, some (grep -ir 'configure  *--help' ...) even 
mentioning 'configure --help', even though 'introduction/beyond.html' already 
includes discussion of 'configure --help'  . For the avoidance of doubt: what 
is being suggested here, is _not_ replicating that intro-info on each page; 
instead, it's just putting a proper demarcation between the two lists as noted.

((Right now, the two lists being spliced together reminds me of the old solemn 
and sage advice, "You shouldn't say things together like that; you could 
confuse a stupid person." -- Peter Cook  .))

> > 
> > In a related vein, given that four of the above-noted five options are stated 
> > to be re auth, could I also recommend noting that (at least) the following auth 
> > methods are enabled by default:
> > ----
> >   --with-shadow           Build with shadow password support (auto)
> >   --with-pam              Build with PAM support (auto)
> >   --with-bsdauth          Build with BSD authentication support (auto)
> >   --with-vpopmail         Build with vpopmail support (auto)
> > ----
> > I think it's worth stating that explicitly so that folks can see at-a-glance 
> > that dovecot does handle those ( - don't hide its light under a bushel). One of 
> > the central considerations, of course, in choosing a pop/imap server is in what 
> > authentication methods can it handle, and how it would in this respect integrate 
> > with other parts of infrastructure. Sure, folks considering using it seriously, 
> > would do their due diligence anyhow and not just make a decision based on a 
> > single 3rd-party page (in this case, the blfs page): but still, it doesn't hurt 
> > to state it up-front by noting the default methods additional to said list.  
> > 
>  If something is optional and automatically detected, we don't
> usually add an explanation of a switch to enable it.  Unless an
> editor thought it was worth mentioning.
> ??en
> -- 
> das eine Mal als Tragödie, dieses Mal als Farce
> -- 
> http://linuxfromscratch.org/mailman/listinfo/blfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page


More information about the blfs-support mailing list