Theo Van Dinter writes: >On Fri, Jun 30, 2006 at 08:05:48AM -0500, Michael Parker wrote: >> add --allow-plugins or something like that, which is off by default. >> Make a nice big warning in the docs about how turning it on will >> distribute new code to their install. Then let the user decide. > >Hrm. I view this as more of a policy decision than a technical one. I'd >really rather not add more complexity into sa-update (more commandline >options, special handling for *.pre and *.pm, etc, etc.)
Good point... >I'm also concerned that our whole sa-update system is a bit immature to >trust it to distribute automatic code updates. Down the road I think >it's a great idea (it works for the anti-virus folks, and it should >work nicely for us too,) but I'd rather get more people using sa-update, >get more work done on sa-update, etc. I'm not *entirely* sure I'm convinced of this; in my opinion, the eval-rule plugins in the updates are already looking like they'll be required. I'm not 100% definite though. let's see if anyone else weighs in ;) Either way, it's quite easy to switch from one to the other; since the build/mkrules script will turn "loadplugin" into "tryplugin", since a failure to load the latter is not an error, and since the sa-update script can simply remove rules/*.pm when building the tarball, it's a matter of a 1-line change in the "build/mkupdates/run_part2" script. Also: it still means that, for new eval rules in the sandboxes, the correct approach is to create an eval-rule plugin .pm right there in the sandbox dir rather than adding it to EvalTests.pm. --j.
