All:

Back in...Feb. I asked if anyone had worked on this and no on responded,
and then I promptly forgot about it ;-).

It's kind of surprising to see the individual Courier packages available
(albeit a bit out of date) such as the IMAP daemon and mailing list
manager available in pkgsrc/mail/, but not the MTA itself.  I personally
prefer it to Postfix/QMail any day. 

http://digitalfreaks.org/~lavalamp/courier-mta-netbsd-pkgsrc.tar

NOTE: I don't have a PLIST quite yet until issue #2 below is resolved!

Anyway, issue #1:

Courier's GNU Autoconf configure script has to be run as a non-root user
(preferably as the user it will run as).  So to accomplish that, I setup
a "do-configure:" target, but I wanted some input on a possibly cleaner
way to go about this:


do-configure:
        ${CHOWN} -R ${COURIER_USER}:${PKG_GROUPS} ${WRKSRC}
        ${SU} - ${COURIER_USER} -c "${CD} ${WRKSRC} && ./configure
${CONFIGURE_ARGS}"


And issue #2:

Courier is big, it's an [e]SMTP daemon, IMAP[s], POP3[s], mail filter,
[ssl]webmail, fax<>e-mail gateway, mailing list manager, and it supports
the following authentication methods: PAM, Shadow, PostgreSQL, MySQL,
LDAP, GDBM/DB (CRAM-MD5 or CRAM-SHA1).  It also installs quite a bit of
bin, sbin, and data files:

sbin: 34
bin: 25
etc: 55

As a rule of thumb, if a package installs more than 10 binaries, it
probably deserves it's own directory to avoid clutter and confusion,
however the approach I've taken in the tar file above is rather
unorthodox and I'm curious what some more weathered pkgsrc people think.
Because it installs so many files, I've personally been taking a
${PREFIX}/{sbin,bin,etc,share}/courier approach like so:

CONFIGURE_ARGS+=        --bindir=${PREFIX}/bin/courier
CONFIGURE_ARGS+=        --sbindir=${PREFIX}/sbin/courier
CONFIGURE_ARGS+=        --libexecdir=${PREFIX}/libexec/courier
CONFIGURE_ARGS+=        --mandir=${PREFIX}/man
CONFIGURE_ARGS+=        --sysconfdir=${PREFIX}/etc/courier  # configs  
CONFIGURE_ARGS+=        --datadir=${PREFIX}/share/courier   # docs etc
CONFIGURE_ARGS+=     --localstatedir=${PREFIX}/var/courier # queue/spool

(${PREFIX}/var/courier being a symlink to /var/courier on a separate
filesystem locally).  Then I have multiple ~root profiles for when I'm
doing Courier administration and not.  I've chosen this
subdirectory-within-directory approach because a lot of Courier's
binaries are ambiguously named and I find it hard to keep track of them
if they were all cluttered into ../.

However, for the purpose of a pkgsrc package, I know this approach will
never fly for the general user base, so the way I see it, there are
three options and we need to choose the lesser of three evils:

1) A very Apache/QMAIL/DOS-like approach:

The user sets a ${COURIER_ROOT}, such as /var/couier

--prefix=${COURIER_ROOT} ...and then --localstatedir={COURIER_ROOT}/data
or some variant	

	*) this requires $PATH and $MANPATH adjustments for everyone 	but
everything is cleanly contained

2) A userland overlap approach

Let everything settle into ${PREFIX} by not setting --prefix= but with
exceptions some for --sysconfigdir = ${PREFIX}/etc/courier to avoid
gross over-clutter.
	
	*) The problem with this approach is that other MTAs might 	install
binaries such as "mailq" and "sendmail" in ${PREFIX}/bin 	and
${PREFIX}/sbin so multiple MTAs can't co-exist on the same 	system.  The
same holds true for man pages.


3) My approach


Issue #3

...Concerns how I'm going about checking which authentication modules to
*disable* and which to enable and the associated buildlink2.mk
dependencies:

The way I'm going about it is an .if defined(Environmental
Variable)-approach {ex, MySQL):


.if !defined(MYSQL_AUTH)
CONFIGURE_ARGS+=--without-authmysql
.endif

However, if I do this, then later in the Makefile I have to do a very
similar check for the buildlink2.mk .include:


.if defined(MYSQL_AUTH)
.include "../../databases/mysql-client/buildlink2.mk"
.endif


The problem is that  I have a lot of duplication.  I know this could be
a lot worse, but I feel pretty certain it could be done better
(certainly better than having a separate Package / Makefile for each
authentication module combination! >:} )



Issue #4

...has anyone seen the buildlink2.mk's for security/gnupg,
comms/mgetty+sendfax, and lang/tcl-expcet? >:}


...anyway, that's that.  I'm looking for any feedback on how I could
improve upon this package to make it more commit-worthy-quality.

-- 

Thanks,
	-Brian

NOTE: When replying to a mailing list post, please be sure to reply to
the /list/ and cc: or bcc: myself as I am unable to promise a timely
response.