From owner-freebsd-ports Wed Oct 24 16:22: 9 2001 Delivered-To: freebsd-ports@freebsd.org Received: from sapas.dppl.net (sapas.dppl.com [216.182.10.231]) by hub.freebsd.org (Postfix) with ESMTP id 1565837B401 for ; Wed, 24 Oct 2001 16:22:04 -0700 (PDT) Received: from volyn.dppl.net (cc375212-a.union1.nj.home.com [24.253.222.7]) by sapas.dppl.net (Postfix) with ESMTP id 4A7B13E06; Wed, 24 Oct 2001 19:21:57 -0400 (EDT) Date: Wed, 24 Oct 2001 19:21:56 -0400 From: Yarema To: Sam Varshavchik Cc: courier-users@lists.sourceforge.net, ports@FreeBSD.org, Neil Blakey-Milner Subject: Re: Courier-MTA on FreeBSD Message-ID: <1023070000.1003965716@volyn.dppl.net> In-Reply-To: References: <668830000.1003930578@volyn.dppl.net> X-Mailer: Mulberry/2.1.0 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --On Wednesday, October 24, 2001 21:40:21 +0000 Sam Varshavchik wrote: > Yarema writes: >> install/deinstall/reinstall/package/pkg_delete/pkg_add all seem to work. >> Optional BUILD_DEPENDS include expect, gpg, [ai]spell and procmail. The >> package does not have a RUN_DEPENDS on the above since it is my >> understanding that removing the above packages will not break a running >> Courier system. > > Correct. 'expect' is only needed to allow login passwords to be changed > via webmail. gpg and aspell are also needed to enable optional webmail > components. Right now, without expect, the change password screen in > webmail will be broken. No big deal, you can fix this later. The expect dependency I don't intend to fix since expect depends on tk which then depends on tcl and X11 and I think it's kinda stupid to force people to install X11 if all they really want is courier. If the expect port ever losses it's dependency on X11 I'll reconsider. For now I was only after having a binary package built with the right paths. So if people install Courier and then RTFM and discover they need expect to change passwords in webmail they can just drop the expect package in place (with all the baggage it carries) and it will automagically work. >> I'm thinking of splitting the port into master/slave ports where the >> slave ports would only build/install authdaemond.{ldap,mysql,pgsql} >> plus related config and support files. This would for the most part >> solve the above db3 linking issue. > > You only need to put authdaemond.* into the corresponding subpackages. > Don't bother with the config files. For extra credit, -mysql should have > authdaemond.mysql, admin-15mysql.html and admin-15mysql.pl. -ldap should > have authdaemond.ldap, admin-15ldap.html, admin-15ldap.pl, > admin-15ldapa.html, admin-15ldapa.pl, and courierldapaliasd. -pgsql > should have authdaemond.pgsql, admin-15pgsql.html, and admin-15pgsql.pl. > If you can specify conflicts, specify that -mysql, -ldap, and -pgsql > conflict with each other. With this packaging, webadmin will not have a > MySQL config screen unless -mysql is installed, etc... This happens to > be exactly how Courier RPMs are built. There are also separate > -webadmin, -webmail, -maildrop, -smtpauth; and several other RPM > subpackages that install various modular components of the whole system. Yeah, I can deal with the extra credit. :) I could probably deal with conflicts as well. I disagree with having to specify that -mysql, -ldap, and -pgsql conflict with each other. The version variable in authdaemonrc can take care of which authdaemond.* is selected. Hypothetically someone might be migrating from -mysql to -ldap or -pgsql and might wanna have two or three different authdaemond variants installed at the same time and be able to bounce back and forth by flipping the version variable. Specifying a conflict in the subpackages would put artificial barriers to such a scenerio. While on the subject I don't like the variable being named version. Could be just me but it throws me off. method or authmethod or something like that would be more apropos me thinks. >> wouldn't resolve any DNS. Rebuilding courier --without-ipv6 solved that >> problem. I only use djbdns and not BIND. So for what it's worth >> courier --with-ipv6 does not work with djbdns. > > This is possibly for the same reason that OpenBSD IPv6 doesn't work > either: some apparent issues with IPv6 header files. On some xBSD > systems, accept() apparently returns a shorter sockaddr_in6 address > structure than what's declared in the header files, which fails my sanity > check. Apparently the header files declare some padding at the tail end > of sockaddr_in6 that is not present in the address structure that comes > back from accept(). I believe that this is wrong. It is reasonable to > expect that accept() on an IPv6 socket will return a sockaddr_in6 > structure, and not something different, with a shorter size. FWIW, the Courier-IMAP port I've been using on my other FreeBSD systems was built with IPv6 and works fine. (I know cause the log entries have all them funny ::ffff:s in the address field.) Then again imapd and pop3d alone might not be doing any DNS lookups. It very well might be that this is only a problem with djbdns. -- Yarema To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message