After some experimenting I have observed that overriding settings from /usr/share/logwatch/default.conf/logwatch.conf in /etc/logwatch/conf/logwatch.conf does not produce consistent results.
For example, if I replace the default detail configuration in etc/logwatch/conf/logwatch.conf with:
Detail = High
It does indeed change the level of detail from the default Low set in /usr/share/logwatch/default.conf/logwatch.conf.
However, if I comment out the line:
#Service = "-zz-sys" # Prevents execution of zz-sys service
in the overridden file then the fact that this line remains in the default.conf version means that the sservice cannot be enabled to run by default without editing /usr/share/logwatch/default.conf/logwatch.conf. Of course doing that means that any update clobbers the local changes.
I am not sure if this a bug or a design feature but it seems to me that on should be able to override all of the default settings for services.
The only way around this seems to be to specify '--service All' on the command line. But then the service entries in logwatch.conf seem to be ignored entirely so that one must also specify the service exclusions on the command line.
I also ran across a rather bizarre 'feature' with the 'DisplayOrder' setting. Evidently, if one gives the same DisplayOrder value to two or more services (say zz-sys which has DisplayOrder = 0.4 and zz-runtime which uses the default value of 0.5 otherwise) then only the last service (ordered alphabetically) is reported. No errors are logged or conflict notices are given either. The other service reports just 'disappear'. However, one can explicitly assign multiple services a DisplayOrder value of 0.5 and all are reported nonetheless, in alphabetic order, along with the other services which simply take the implicit default value.