Evolution with bogofilter: wherefore are thou?

[Tim]

On 14/01/15 08:42, Paul Smith wrote:
> ^Subject: s/are/art/ oops...
>
> On Wed, 2015-01-14 at 07:46 +1100, Tim wrote:
>> On 14/01/15 05:35, Paul Smith wrote:
>>> What can we do to help get this fixed in Ubuntu 15.04?  The bug was
>>> filed over a year ago and no maintainer seems interested in responding
>>> to or fixing it.
>> bogofilter is disabled in Ubuntu since bogofilter is in universe, and
>> packages in main (i,e. evolution) can't build against universe
>> packages.
> It's frustrating when arbitrary distribution policy decisions end up
> costing you the use of critical software you rely on every day.  As an
> end user do I really care whether something in main depends on something
> in universe?  Heck I don't even care if they move the entirety of
> Evolution into universe to solve this problem; it all looks like
> "apt-get install" to me.  I just want my software to work and my spam to
> be filtered, like it was before I upgraded.
Its not really just an arbitrary policy, packages in main are guaranteed supported
by canonical, this includes much stricter security requirements etc. packages in universe are not.
>
> Does anyone know why this happened in the first place?  It used to work.
> Was the policy originally ignored in this case?  Was bogofilter demoted
> from main to universe for some reason?  Did anyone realize this was a
> regression at the time?
Prior to 3.8 bogofilter was just a plugin, and that could be satisfied at runtime. It now a core module
in libevolution and this requires the build-time dep. bogofilter was never in main afaict. Many people probably use their email provider
filters, so perhaps it did go unnoticed.
>
>> The only way to fix this is get bogofilter promoted to main via an MIR
>> [1], Im not sure what the chances of getting that approved would be
>> though, particularly since bogofilter doesnt appear very active
>> upstream.
> Well, there was a bug fix upstream in November, and I don't see a large
> number of launchpad issues that are not addressed.  Software that is
> stable and works shouldn't need to be continuously fiddled with just to
> keep up appearances for main inclusion (IMO).
It doesn't need to be fiddled, but it does need to be supported by upstream. For example security fixes and what not.
>
> Anyway it seems to me that it should be possible to build Evo with
> potential support for bogofilter but not list it as a requirement in the
> package; if you install bogofilter then you can use it in Evo and if
> not, not.  That would appear to me to be exactly the point of having
> "plugins".  Maybe Evo's plugin support doesn't work like that but it
> seems like something could be shimmed or symlinked or wrapped or
> something.
bogofilter support is now a core module and links directly to evo libraries, that is a bit different to plugins in the usual sense where they
can usually be built externally and then loaded dynamically.

Now if the bogofilter module can build without bogofilter then maybe its possible to enable by patching evolution to use runtime detection
instead of build time
>
>> Anyway you would probably be better off checking with ubuntu-desktop
>> team since they maintain evolution.
> I feel somewhat Quixotic at this point, but nothing ventured and all
> that... I'll give it a whirl... thanks for the pointers!
>