http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5171
------- Additional Comments From [EMAIL PROTECTED] 2007-02-05 17:02 ------- (In reply to comment #18) > So the reason I pushed this to 3.1.9 originally is that there doesn't seem to > be > a consensus on whether or not this is a good idea that even solves the > problem, > if in fact there is a problem with the code. I consider sa-update being able to install an update that could encounter parsing/whatever errors when spamd is restarted to be a problem. IMO if the goal is to be able to automatically restart spamd after sa-update installs an update we should be sure that the update will actually lint with the particular system's config. Maybe that's not our goal. Although, spamd restarting may not be avoidable (the system may restart), so installing an update that won't lint on the particular system seems like a bad idea to me either way. I thought I'd convinced you that we shouldn't be doing the current partial lint in bug 5044. Although your bug 5044 comment #10 could have been you just hoping I'd shut up about it. :) > For instance, the same problem will exist if people comment out plugins and > then > get an update that doesn't properly have ifplugin conditionals around > plugin-dependent rules and associated configs. I don't think that's the same problem, rather it's a problem that's already handled. The update would fail a lint and wouldn't be installed. > This issue also, currently, doesn't impact 3.1 since the core eval rules are > still in EvalTests.pm, and all of the plugin-dependent rules are enclosed in > conditionals. Sure it does. If our channel, or anyone else's (like SARE's SPF rules which have had typo problems before), has invalid/typo'd config lines inside ifplugin lines the sa-update lint isn't going to catch it, but it will show up when spamd is restarted (if the user has that plugin enabled). I just don't see the point in linting a part of the update. Why only lint everything outside of ifplugin lines? Why not lint everything inside ifplugin lines (for plugins that are enabled) and ignore everything else? Neither way makes any sense to me. Either the update should be checked to see if it'll work with the system's config or it shouldn't be checked at all. > So in short, I'm around a -0.8 on this patch -- I'd rather solve the problem > correctly via conditionals than put in a kluge which doesn't really change the > behavior in the long run. Conditionals don't solve the problem since they're required for the problem to even exist. The problem I'm looking to solve isn't something about updates with missing conditional lines (we both agree those updates are broken and shouldn't be used). The problem is dealing with updates that have broken lines within conditionals. Kluge? I don't know. The lint simply uses the .pre files found in the defined site config dir (the same .pre files spamd/spamassassin is actually going to use itself). The end behaviour is certainly different. The current way will load a broken update if the brokenness is contained by conditionals. The proposed way won't. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
