On Wed, 2015-01-14 at 17:36 +0100, Milan Crha wrote: > I would revert part, or whole, commit [1]. If I read it properly, then > the only reason is to get the bogofilter path during configure, > instead of having it hard-coded.
Well, life is never simple. It looks like after the change you pointed me to, Milan, in Evo 3.8 or so, Matthew completely removed the "unavailable" function from the bogofilter plugin: https://git.gnome.org/browse/evolution/commit/?id=c539a9ec20f46 This latest change works well for private builds but from the standpoint of a distribution / package maintainer, assuming that the software available on the build system is also always available on the runtime system is a problem (unless you're willing to forcibly require all the plugin packages to be installed along with the software, in which case it's not really a plugin anymore :-)!) IMO it would be better to revert this change, but it's not clear to me what exactly the problematic behavior was that caused the change. Ideally you'd have something where the "plugin unavailable" could give some kind of reason. So, in the Evo plugins dialog if Evo is compiled with bogofilter support but no bogofilter is found, you would see a greyed out "Junk filter using Bogofilter" that is not selectable and an extra statement (hover popup?) saying "Install bogofilter to enable". Don't know how feasible this is. _______________________________________________ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
