Evolution does not need spamassassin to compile or run. Accordingly, Gentoo should not force it to be installed. This is what USE flags are for.
i loathe to introduce another useflag like "nospamassassin". but if enough people insist. i for one don't really mind another few packages to get spam filtering, the combined dep size isn't nearly as big as libgtkhtml/gal/soup and co.
yes please. spamassassin pulls in 12 other packages and I don't even use evolution.
I use evo but do my spam filtering server-side and have no use for spamassassin on my laptop - so a USE flag would make sense
odd, seeing that if you don't use evolution, you probably should of gone for gnome-light or something.
Please add an use flag +spamassassin. I think, at least half of the evolution users don't need SA, as they * are not using Evo as mail client * have server side Spamfiltering * does not like SA * ...
To get back to the initial comment, gentoo should force it. For the UI to work as expected, SA is needed. It is a runtime dep and not optional (it doesn't break in a visible way, but it is broken behaviour). That being said I do agree that in some situations it might not be very useful, what I'd like to see is some UI feedback that SA is not available : grayed out icons, a dialog, etc. for it to be made optional.
I agree with foser. If the Evolution team decides to implement "grayed out icons, a dialog, etc" when SA is not available, then it should be optional. Otherwise, I like it as an RDEP. This may sound foolish, but until I saw Spamassassin as a new dependency, I had no idea why spam filtering in Evolution wasn't working. I'm sure there are others like me.
OK, I see what the issue is, thanks foser. There is an upstream bug on the UI aspect at http://bugzilla.ximian.com/show_bug.cgi?id=57091 - I'll cc myself on it, put a fake spamassassin ebuild in an overlay and wait for the UI issue to be resolved. Unless anyone objects I think this can be closed.
Ed, instead of a fake ebuild, you could just put 'mail-filter/spamassassin' into '/etc/portage/profile/package.provided'. If the file or directory doesn't exist, you will obviously have to create it. You can read about that here: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=5#doc_chap3
resolving this upstream for now, we'll keep an eye on the upstream bugreport.
*** Bug 81441 has been marked as a duplicate of this bug. ***
Created attachment 50950 [details] mail-client/evolution-2.0.2-r1.ebuild The packages.provided will not work when a new version gets out because of the annhability to specify wildcards in that file. What the upstream developper do does not mean we have to oblige by them. I find it utterly stupid to force SA on every client when clearly a lot of people will have SA on the server side. It's not because Ximian/Novell are being dumb that we also have to be dumb. No need to be Einstein. It's crystal clear they got it wrong. Give the users what they want and implement the darn "nospamassassin" USE flag. It should at least be available on the bugzilla. What's the big deal?
all no-flags are broken by design, see discussion on gentoo-dev. (double-negations are bad by design) Also, see the discussion about functionality as expected and feedback for a good reason why not to break things for users.
*** Bug 115932 has been marked as a duplicate of this bug. ***
*** Bug 125341 has been marked as a duplicate of this bug. ***
*** Bug 130202 has been marked as a duplicate of this bug. ***
If you object to spamassassin, you can instead use bogofilter with the bogofilter use flag. It does pull in bogofilter, but that's one small C package, not the multitude (and constantly growing) set of perl deps that spamassassin pulls in.
*** Bug 180968 has been marked as a duplicate of this bug. ***
For the record: evo 2.12 will have a bogofilter and a spamassassin flag; if neither are there, neither will be pulled in as a dep. 2.11.x in the overlay already has this.
dang, are you sure you want to do this ? In any case the UI will stay even if bogofilter and spamassassin support is not compiled because of other providers (exchange, ...). I can get you the proper gnome's bugzilla link if you want. Anyway, if we go that route, I think BIG FAT WARNING will be appropriate for evolution's ebuild about spam filtering support :)
Sure. Using spammassassin/bogofilter is not a compile time choice anymore, it's a runtime choice, so all the flags control is the deps. I plan on submitting a patch that grays out the spam buttons unless one of the plugins reports it's available.
Ok fine with me then :) relevant bug is http://bugzilla.gnome.org/show_bug.cgi?id=257091
