http://bugzilla.spamassassin.org/show_bug.cgi?id=4153
------- Additional Comments From [EMAIL PROTECTED] 2005-05-21 09:25 ------- Subject: Re: [review] RFE : Spamc patch for config file -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On (21/05/05 08:08), [EMAIL PROTECTED] didst pronounce: > Unless a specific define as been set at compile time, spamc will never > attempt to stat a config file, unless that config file was passed to it > via -F <somefile>. > Understood - but should the #define be on or off by default? Ie., should it #define CONFIG_FILE "@sysconfdir@/spamc.conf" or #define CONFIG_FILE NULL by default? > If so desired, the person who compiles spamc can set the define that > will a) cause it to stat a single file in the system config directory > (what the current proposed patch now allows for), or b) go search > through several directories to find a config file (what the current code > in trunk allows for), or c) use whatever was passed in via -F <somefile>. > Wait, I think I may have misunderstood you. What you're saying is something like : #define CONFIG_FILE "@sysconfdir@/spamc.conf" // default config #define USE_CONFIG 0 // don't use a config file #define USE_CONFIG 1 // use a single config file #define USE_CONFIG 2 // search if default isn't found Then, in spamc.c check which "option" was chosen and do what the admin has requested during compilation. Have I got what you mean this time? > My thinking is, why take the stat overhead if it's never going to be > used? It should be easy enough to provide that functionality to a local > admin if they so desire, I see the usefulness of allowing a config file > in multiple places but its overhead is too great IMHO. > Yes, I agree. I never timed a run of spamc with the config patch to see what kind of overhead it added. I really don't see the need for any admin to need spamc.conf in multiple places, so while the functionality for searching for a config _could_ be useful, maybe a prompt from Makefile.PL to specify the location of a spamc.conf would be handier? > I'll backtrack a little with the following thought, this does create a > situation where one spamc will behave differently from another spamc, > will this cause support nightmares? How do you tell how a particular > spamc was built? Maybe -V should print out the compile time information > (see mutt -v) as an example. > It really shouldn't behave very differently, since the config file is parsed in the same way as the command line arguments. The main difference will be whether or not a config file is being used. This could add options that users don't know about (but, obviously, the admin would), and could lead to misleading bug reports if a user reports directly to SA instead of to the admin running their local SA install. There'll also be the extra overhead of reading spamc.conf, if it's enabled. That said, it'd be easy enough to add to the -V argument, and state what config option is being used, if any. Let me know what you think, and I'll work on it. I'm away all next week though, so I really only have today to work on it. Personally, I would think patch #2879 should cover anything an admin would want, without the overhead of searching for a config file. - -- Chat ya later, John. - -- BOFH excuse #1: clock speed -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCj2K4QBw+ZtKOvTIRAvLoAJsHXUB7i2foyitHtTICFW+hG1+00QCeP2QX /gfd9O0dP/0vdNX9R00UAhQ= =26Pv -----END PGP SIGNATURE----- ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
