From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25287 invoked by uid 1002); 9 Sep 2003 12:40:32 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 23405 invoked from network); 9 Sep 2003 12:40:32 -0000 Date: Tue, 9 Sep 2003 12:38:18 +0000 From: "Hallgrimur H. Gunnarsson" To: gentoo-dev@gentoo.org Message-ID: <20030909123818.GA17497@data.is> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.4i Subject: [gentoo-dev] comments on qmail 1.03-r12 ebuild X-Archives-Salt: c770dcfa-5964-427f-ae84-7793bd7ba631 X-Archives-Hash: e99111e9e36ed42ab2fe555800f4455c Hello all! I just filed my first bugs and I wanted to get the opinion of my fellow users. Since some of my comments involve more things than qmail I thought I'd follow it up by also posting it here in my first e-mail to this list. So, greetings to you all from sunny Iceland ! :-) Here are my comments for the latest qmail test ebuild (1.03-r12), most of it applies to earlier versions as well. - [#28256] On creating a maildir and .qmail in ~root [CUT] # make sure root can get some mail [ ! -d /root/.maildir ] && ${MAILDIRMAKE} /root/.maildir [ ! -e /root/.qmail ] && cp ${FILESDIR}/${PV}-${PR}/dot_qmail /root/.qmail [ -e /root/.qmail ] && chmod 644 /root/.qmail [/CUT] Earlier in the ebuild an alias is set up for root, so this is unnecessary. Besides, even if there wouldn't be an alias, the mail would bounce since mail is never delivered to the root user in qmail. - [#28257] On copying dot-qmail to /etc/skel/.qmail This is redundant. The same file (files/dot-qmail) is used for defaultdelivery, which is how it should be done. - [#28258] On using dot-forward in defaultdelivery I think dot-forward should not be default in the defaultdelivery. It's okay to have the package installed, so users can add it themselves if they need it, but most users dont need dot-forward, so it's an extra invocation per message in the delivery pipeline. - [#28260] On using .maildir instead of Maildir I know this has been brought up before (bug #27154) and Robin Johnson said he strongly believed that .maildir was better than Maildir because: [QUOTE from #27154] because i've seen lots of [l]users select everything visible in their home directory, and delete. 'rm -rf *' and it's gone. at least with .maildir, it is protected. Furthermore, nothing in any of the maildir standards specificied the actual name of the directory. [/QUOTE] I dont think this is such a good reason. Yes, there's nothing in the maildir standards about the name, but that doesn't mean you have to find a new one. Alot of programs assume the name to be Maildir, and AFAIK gentoo is the only distribution that uses .maildir, so for one it's a compatability issue. Furthermore, I think it's up to the system administrator whether he wants to dumb down the system, I for one would prefer to have Maildir as the default. - [#28259] Honor mbox/maildir USE flags qmail doesn't honor the mbox/maildir USE flags. The postfix ebuild does this, so I think it'd be the right thing to do in qmail too. The mbox/maildir flags aren't mutually exclusive, and since most programs support to have both simultaneously the question becomes which one takes precedence if both are enabled. In the original qmail package Mailbox delivery is the default. In addition, which one (mbox/maildir) is used if neither is specified (?), shouldn't one of them be in make.defaults, or should it be up to the package to decide? I can think of one reason why qmail doesnt honor the USE flags. Mbox seems to imply delivery to /var/mail/$USER in gentoo, which is not possible to do in defaultdelivery. I think delivery to ~/Mailbox is the right thing to do. Most programs support it and/or use MAIL to find the mailbox. Administrators can also create symbolic links in /var/mail for compatability if they really need it. That's all for now! Thanks for reading and I welcome all comments! -- hhg -- gentoo-dev@gentoo.org mailing list