Evolution calls out to spamassassin to do client-side junk mail
filtering on accounts where you enable it.  So if you don't want to do
client-side filtering, yes, this dependency (and the perl deps it
pulls in) is unnecessary.

However, if you don't have it installed and turn on client-side junk
filtering for an account, evolution will silently fail.  The package
could be patched to give better error handling, and warn about the
missing feature in the account configuration dialogs (or hide the
feature) - though that's a low priority job for me.  

The upstream maintainers specifically asked me to add this dependency,
presumably in order to avoid having to write the handling, and to
minimise bug reports they get involving calling out to missing
spamassassins.

(Does RPM have any kind of "partial dependency" feature, where we can
say that a package will be improved by the presence of another package
, but doesn't need it?  Dependencies seem to be very much a boolean
property to me)

Adding the requirement for FC3 as a quick and dirty workaround for the
brokenness does seem like a reasonable enough answer, I suppose.

Can we back it out in rawhide though and fix the thing properly?

Well, Ubuntu shipped an Evo without spamassassin and thats never the
best idea because suddenly junk mail filtering seems really fast (just
that it doesn't work). Short of patching out the Junk/No Junk icons
when spamassassin isn't detected, doesn't this become rather difficult?

How about fixing the nonexistent error handling so that it correctly
warns the user that SA isn't present or isn't working, and behaves as
if junk filtering is disabled? And yes, disabling the Junk crap would
be nice -- it would be especially useful to be able to read my 'junk'
IMAP folder with Evolution again, rather than only being able to
access it with PINE.

The error handling was going to be fixed for FC4 so the bogus requirement can be
removed, wasn't it?

How do we handle "partial dependencies"?  Evolution's plugin system may have
made it easier to patch things so that the spamassassin dep really is optional
(with appropriate modifications to the UI).  However, I'm not sure how to do
this without causing complications in the installer for the end-user.

I believe most people won't want to worry about this, and would want the
client-side junk filtering in Evolution without having to tick anything in the
installer.

So perhaps we could factor put the client-side junk filtering into an
evolution-junk-filtering package, built from the evolution.src.rpm, which would
have the spamassassin dep.  This package would be selected by default if
Evolution was selected, but could be unselected for people wanting to optimize
their dependencies).

Adding katzj to CC, hoping for suggestions on how to achieve this in the installer.

Regarding comment #6, to my knowledge rpm does not offer anything equivalent to
Debian's "recommends" or "suggests" tags for "partial" dependencies.

Ironically, Debian's Evolution package only "recommends" SpamAssassin, which
leaves it susceptible to the confusing behavior that Dave warned about in
comment #1.  That appears to have been reported upstream [1].

Closing this bug as UPSTREAM and will continue to track the problem there. 
Until the usability issues get sorted out, I'm afraid the spamassassin
requirement will have to stay.

[1] http://bugzilla.gnome.org/show_bug.cgi?id=273041