When I emerge crm114 it has a depend on procmail. I use maildrop and don't want to install procmail on my system. Why is procmail mandatory? Reproducible: Always Steps to Reproduce: 1. emerge crm114 2. 3. Actual Results: [ebuild N ] mail-filter/procmail-3.22-r6 [ebuild N ] app-text/crm114-20040820 Expected Results: [ebuild N ] app-text/crm114-20040820
John, would a virtual/mda dependency possible, or does it directly depend on formail/procmail?
The crm114 mailfilter.crm script calls formail in many places. As far as I am aware (I haven't really done exaustive searching) procmail is the only package that provides that. If you don't use the mailfilter.crm script that comes with the crm114 package, then procmail isn't needed. There has been some work with the mailfilter.crm script to remove the dependency on procmail, but nothing has been accepted into the mainline code, and I don't think the patch is really feasible to maintain alongside it.
Added patches to bug #66522 (newest crm114 release) for a proposed solution to the procmail dependency. Simple description is that it adds a use flag to remove the dependency and warns the user that the included mailfilter.crm script won't work without some hacking.
John, I dunno if we should be adding a "noprocmail" USE flags. no* flags are rather frowned upon. I reckon people who don't want procmail should just inject it and carry on with their lives. If, however, there will be work done to completely make it independent of procmail, that's a different story. Till that happens, though, procmail isn't such a heavy dependency, and also, it's injectable. That's my 2 pesos.
If crm114 requires procmail is someway, I miscategorized the bug. If that's the case, the problem is that maildrop is part of courier and currently under Bug #68740 http://bugs.gentoo.org/show_bug.cgi?id=68750 you cannot have Courier and procmail simultaneously installed. The current state of ebuilds prevents you from using crm114 with Courier as your MTA. I didn't know crm114 actually needed part of procmail.
Seemant, you're the dev, so whether or not you want to add a noprocmail useflag is up to you :) The current status of CRM114 is thus: the crm114 binary does not require procmail to be installed in order to work. The mailfilter.crm script which is the spam filtering script distributed with the crm114 package (and the script most people use for spamfiltering with crm114) depends on the formail binary being present (and as far as I can tell, formail is only provided by procmail). So if a user wants to do spam filtering with crm114 and not have procmail installed, they either have to write their own crm filter script, or hack the provided one to use something other than formail. I guess the question is really, what do people mostly do with crm114? If it's just text processing and they are wrting their own scripts, then procmail isn't really necessary. If it's spam filtering, and we want the crm114 package to work "out of the box" then procmail is required. I hope I have explained myself well.
John, actually I rely on your expertise with crm114 and USE flags :P OK, so how about this -- I think we have an existing mta flag -- would that be more applicable? Barring that, perhaps we can have someone (courier user, I should think) hack up a script for maildrop and then we can virtualise the dependency? Just stuff to think about...
well, if there is an existing mta flag, then I'm looking in the wrong place (online use flag list, and /usr/portage/profiles/use.local.desc). I'd be fine with that, but if there isn't an existing mta flag and one would have to be created, then I think it might make more sense to create a spamfilter flag instead, since it's the use of the spamfilter part of crm that really determines the dependency on procmail. Depending on what we decide, I'll hack up the changes to the ebuild. However, do I open a new bug with the changes? or do I add it to bug #66522 (which has been marked fixed)?
Okay, this bug has been sitting around for a long time, I'm sorry for the wait. The solution I'm preparing to commit is to use a USE flag as suggested in the bug. I'm open to suggestions though. At the moment, I'm torn between: - mailfilter (may be confused with sendmail milter) - procmail (some may disable it and not realise that it disables the installation of mailfilter.crm) ... but anything anyone comes up with is welcome.
I'd suggest creating a "spamfilter" use flag. And if it's enabled, then all it should do is warn the user that they can't using mailfilter.crm will break. Tom, I don't know if you're on the crm114 mailing list, but this discussion was raised on it a little while ago. In the future they are either going to implement formail in crm114 or just package formail with crm114. Anyway, hopefully in the future the entire dependency on procmail will actually be removed from the crm114 package itself.
For what it's worth bug 68750, which was what made this bug a real problem, has been closed. This isn't much of an issue any more for, at least.
Rob, glad that's now the case, but I want to get this into a USE flag because a lot of people may not be using crm114 for mailfilter.crm, so the procmail dependency may be unwanted in the first place. I'll fix the ebuild up soon. Thanks, Tom
The newest bleeding edge crm114 release (which isn't even on the website yet) has the dependency on procmail removed. They replaced formail with crm114 code that does the same thing. They are ironing out some bugs in the latest release, and I expect another testing version soon, but basically, the next offical release will take care of this bug without any extra use flags. Perhaps we just want to wait a little longer?
Ah, in that case you're right. Thanks for the information, John.
Just submitted ebuild for new version of crm114 tat removes dependency on procmail (#89851). So once that's accepted, I think this bug can be closed.
New version in CVS with the procmail dependency removed. Thanks everyone.
