[blfs-support] New dovecot page: '--with-...' specs.
zarniwhoop at ntlworld.com
Thu Nov 14 08:08:48 PST 2013
On Thu, Nov 14, 2013 at 11:40:42AM +0000, akhiezer wrote:
> 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.
> 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.
das eine Mal als Tragödie, dieses Mal als Farce
More information about the blfs-support