Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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.