Bug 377381

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.

(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.

> 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.

(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?

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.

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.

(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.

(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.

Fixed in evolution-2.21.3-4.fc9.  Feel free to reopen if you spot problems.