oh, I should point out -- one issue with this is that 'spamassassin --lint' is
often used to check the system-wide settings, e.g. from the rules-du-jour
scripts.  this would be a case where a previously-working 'user_prefs' file
stops working, which would interfere with that.

need to think about this a little for 3.1.0

I'm leaning towards having an array of settings that were previously part of
core,  are now in optional plugins, and will be ignored for --lint, in Conf.pm.

this will only affect --lint warnings, and will not interfere with their use if
the plugin *is* loaded.

thoughts?

Subject: Re:  old user_prefs files now fail --lint due to ok_languages being optional

Could lint be arranged to give a warning like "option 'foo_blarf' only
applies to the Wazzit::DNS plugin which is not currently loaded"?

This way you are admitting the option is meaningful rather than misspelled,
but also hinting that it isn't useful in the current configuration.  (And
the user might have had every reason to believe that it was meaningful, not
realizing there is another plugin to load.)

Subject: Re:  old user_prefs files now fail --lint due to ok_languages being optional

On Tue, Jun 07, 2005 at 09:52:30PM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> Could lint be arranged to give a warning like "option 'foo_blarf' only
> applies to the Wazzit::DNS plugin which is not currently loaded"?

How would the default SA know what options go with what plugins without
loading the plugin?

'How would the default SA know what options go with what plugins without
loading the plugin?'

by having a list in Conf listing the now-moved-to-plugins set of old settings,
as discussed in comment #3.  personally I'd prefer to just list the settings,
and not have to keep track of the plugin names there too; the warning could just be

  setting ignored (no longer in core, now in optional plugin): ok_languages

--j.

Subject: Re:  old user_prefs files now fail --lint due to ok_languages
 being optional

bugzilla-daemon@bugzilla.spamassassin.org wrote:

>by having a list in Conf listing the now-moved-to-plugins set of old settings,
>as discussed in comment #3.  personally I'd prefer to just list the settings,
>and not have to keep track of the plugin names there too; the warning could just be
>
>  setting ignored (no longer in core, now in optional plugin): ok_languages
>
>  
>

This doesn't scale to third-party plugins that we have no control over.

yes.  this is for a specific subset of config settings, to quote comment 1:

'user_prefs files from previous releases may
contain this line -- we did encourage it, after all'

specifically, settings that *were* part of core, but moved to optional but
disabled-by-default plugins in a later release.

Subject: Re:  old user_prefs files now fail --lint due to ok_languages being optional

On Wed, Jun 08, 2005 at 10:09:30AM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> specifically, settings that *were* part of core, but moved to optional but
> disabled-by-default plugins in a later release.

This will also confuse users and net us a bunch of tickets:

- I have [insert config here] set in my local.cf, and --lint doesn't show any
  errors, but the setting isn't working.  Why not?

Then we'll have to explain that the plugin isn't loaded, but we accept and
ignore the old options.  I'd rather have stuff not work, then when they run
--lint it tells them that old options aren't available anymore.

If we didn't ignore the option, we'd have to alert the user about it (which I
think is a bad idea, it should be --lint only imo), which we already do:

[32511] info: config: failed to parse line, skipping: ok_languages en

Granted, instead of saying it failed to parse it could say "X functionality
moved to plugin", but that's not going to help most people anyway.

Subject: Re:  old user_prefs files now fail --lint due to ok_languages being optional

> How would the default SA know what options go with what plugins without
> loading the plugin?

For the standard plugins, from someone coding up a list of the options that
belong to the plugins.  Since most of these plugins seem to be replacements
for existing syntax this really shouldn't be too hard.

Sending        lib/Mail/SpamAssassin/Conf/Parser.pm
Sending        lib/Mail/SpamAssassin/Conf.pm
Transmitting file data ..
Committed revision 190711.