On Sat, 4 Aug 2007, Theo Van Dinter wrote:
On Fri, Aug 03, 2007 at 10:59:31PM -0400, Dan Mahoney, System Admin wrote:
Is there some default mechanism loading these things (for example, I
notice loadplugin Mail::SpamAssassin::Plugin::DKIM is only in v312.pre),
and is it safe to remove the old ones?
So then, what if, for example, nothing else had loaded
Mail::SpamAssassin::Plugin::DKIM?
If nothing loads that plugin, then you don't get the functionality. SA reads
*.pre, so as long as a plugin is loaded in one of them, it's loaded.
It wasn't in the other files, even in a commented out format?
Should there be a "Lint" of all the possible modules (and worst-case
scenario, I get an error if I try to load a module twice)
You can't list all the possible modules, since they can live anywhere. You
could get a list of the standard/default modules, and any modules that an
update channel gives you though.
No, but YOU (the SA team) can, in fact, list all of the modules that you
are shipping with a specific version of SA, in a commented (and possibly
commented out) version of $version.pre.
Notes in there such as:
'"Mail::SpamAssassin::Plugin::DomainKeys" is officialy outdated by
"Mail::SpamAssassin::Plugin::DKIM"'
would be nice things too (as presumably, nothing is going to ever REMOVE
that old module from its installed location for those of us using the
make, make install method, and because SA will still read the
three-versions-ago command to LOAD that module.
However, I don't know what a lint would do for you. Plugins are optional (*),
so not loading them isn't a reportable problem. In fact, that's one of the
main benefits of having plugins: being able to not load certain functionality,
reducing the amount of resources needed to run SA, etc.
Maybe I didn't mean the same thing by LINT you thought I meant? Under
BSD, there's a kernel config file called LINT that lists every possible
kernel config option (even cross-incompatible ones) so you can at least
see and grep for them all. In older versions, this was fully commented.
In more recent versions, it's programmatically generated, which means
there's no nice human readable comments, but that it's more likely to be
all-inclusive.
In the case of SA, the printing of such a message/description could come
from the self-contained POD documentation.
While I feel it's my duty as an admin to know which modules I installed
myself, and which were "stock" (pretty simple, based on which config file
loads them from where, in most cases), it's only stated in the included
docs that NEW modules are in $version.pre (which doesn't help AT ALL if I
missed a version bump, or am installing clean).
Even now, there could be functionality I'm missing, simply because I
haven't installed every minor version in between.
-Dan
--
"If you aren't going to try something, then we might as well just be
friends."
"We can't have that now, can we?"
-SK & Dan Mahoney, December 9, 1998
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
