Bug 377381 - No spam filtering by default
No spam filtering by default
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Matthew Barnes
Fedora Extras Quality Assurance
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-12 04:57 EST by Bastien Nocera
Modified: 2007-12-10 15:49 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-10 15:49:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bastien Nocera 2007-11-12 04:57:55 EST
evolution-2.12.1-3.fc8

In previous versions of Evolution, spamassassin was installed and used. In F8,
the Bogofilter and Spamassassin plugins are installed, but they don't require
their backends, so they do nothing.

My recommendation:
- split the spam filtering plugins into subpackages
- make them both provide "evolution-spam-filter"
- make each one of them depend on the necessary backend packages
- make sure that comps and the default configuration point to a reasonable default
Comment 1 Matthew Barnes 2007-11-12 12:13:06 EST
Interesting idea.

I assume the "evolution-spam-filter" pseudo-package is there to enforce mutual
exclusion between the two junk filtering plugins?  Is that really necessary? 
Evolution allows you to have both backends installed and switch between them.

The junk configuration UI, by the way, is horribly redundant.  Simply enabling
the "Bogofilter junk plugin" ought to be enough to tell Evolution to filter my
mail for junk using Bogofilter.  Instead I have to:

  1) Enable the junk filtering plugin.

  2) Enable junk filtering in Preferences.

  3) Select the junk filtering plugin I just enabled in Preferences.

Perhaps enforcing mutual exclusion at the RPM level would help here.
Comment 2 Bastien Nocera 2007-11-12 13:04:39 EST
(In reply to comment #1)
> Interesting idea.
> 
> I assume the "evolution-spam-filter" pseudo-package is there to enforce mutual
> exclusion between the two junk filtering plugins?  Is that really necessary? 
> Evolution allows you to have both backends installed and switch between them.

No, it's that the main evolution package can require evolution-spam-filter, so
the user only needs one of those installed. Either spamassassin, or bogofilter.

> The junk configuration UI, by the way, is horribly redundant.  Simply enabling
> the "Bogofilter junk plugin" ought to be enough to tell Evolution to filter my
> mail for junk using Bogofilter.  Instead I have to:
> 
>   1) Enable the junk filtering plugin.
> 
>   2) Enable junk filtering in Preferences.
> 
>   3) Select the junk filtering plugin I just enabled in Preferences.
> 
> Perhaps enforcing mutual exclusion at the RPM level would help here.

I don't think that's necessary, but maybe the spam filtering plugins could be
special-cased, and not have to be enabled in the plugins dialogue, but rather by
the preference in the mail prefs.
Comment 3 Matthew Barnes 2007-11-12 13:57:38 EST
> No, it's that the main evolution package can require evolution-spam-filter,
> so the user only needs one of those installed. Either spamassassin, or
> bogofilter.

Okay, got'cha.


> I don't think that's necessary, but maybe the spam filtering plugins could be
> special-cased, and not have to be enabled in the plugins dialogue, but rather
> by the preference in the mail prefs.

This bug spawned a lively discussion on #evolution about the shortcomings of the
current EPlugin framework.  I think there's a consensus it's not scaling well as
we continue to pile on more and more plugins.  I promised to put together a wiki
page about these issues and hopefully that will draw further interest.
Comment 4 Matthew Barnes 2007-12-10 10:58:11 EST
(In reply to comment #2)
> No, it's that the main evolution package can require evolution-spam-filter, so
> the user only needs one of those installed. Either spamassassin, or bogofilter.

Finally getting around to attempting this today.

I added evolution-bogofilter and evolution-spamassassin subpackages with the
appropriate requirements, and will add evolution-bogofilter to comps.

Now I'm questioning whether the evolution-spam-filter requirement is necessary,
in case the user prefers not to use junk filtering at all and objects to being
forced to install a junk filtering package regardless.  Seems like it would be
better suited as a recommendation than a requirement if Fedora were Deb-based.

But I have no strong opinion one way or the other.  What do you think?
Comment 5 Bastien Nocera 2007-12-10 11:03:49 EST
Leaving out the spam filtering dep from the main evo package, I guess it's not
any worse than right now for upgrades, and new installs would get it installed.

Fine by me.
Comment 6 Matthew Barnes 2007-12-10 12:57:58 EST
Got a first cut done, but discovered that installing evolution-debuginfo now
drags in both evolution-bogofilter and evolution-spamassassin (and their
backends).  Looks like evolution-debuginfo has symbols for
liborg-gnome-bogo-junk-plugin.so and liborg-gnome-sa-junk-plugin.so, both of
which live in subpackages now.

Do I need separate debuginfo packages for the two spam filter packages?  Not
sure how to set that up in the spec file.
Comment 7 Bastien Nocera 2007-12-10 13:45:21 EST
(In reply to comment #6)
> Got a first cut done, but discovered that installing evolution-debuginfo now
> drags in both evolution-bogofilter and evolution-spamassassin (and their
> backends).  Looks like evolution-debuginfo has symbols for
> liborg-gnome-bogo-junk-plugin.so and liborg-gnome-sa-junk-plugin.so, both of
> which live in subpackages now.
> 
> Do I need separate debuginfo packages for the two spam filter packages?  Not
> sure how to set that up in the spec file.

That's an annoyance from recent debuginfo changes, and have nothing to do with
symbols. The debuginfo just (stupidly) requires all the sub packages.
Comment 8 Matthew Barnes 2007-12-10 14:50:20 EST
(In reply to comment #7)
> That's an annoyance from recent debuginfo changes, and have nothing to do with
> symbols. The debuginfo just (stupidly) requires all the sub packages.

Wow, that's really bone-headed.  It's hard enough to get users to install
debuginfo packages for bugs they report.  Now they have a legitimate reason to
refuse ("drags in too many extra packages").

In any case, I guess I'll submit the package as is then.
Comment 9 Matthew Barnes 2007-12-10 15:49:29 EST
Fixed in evolution-2.21.3-4.fc9.  Feel free to reopen if you spot problems.

Note You need to log in before you can comment on or make changes to this bug.