Won't the rules tarball be processed and installed with sa-update and the only difference is it won't use LWP/etc. to download the file?

Not necessarily.

Eg, the Fedora RPM SPEC file just untar's the rules into place.

IMO, these dependencies should stay as the project is trying hard to move towards rule updates instead of engine updates.  Additionally, the spec file should likely be running sa-update to install the rules from a local tar instead of reverse engineering the proper location.

(In reply to comment #3)
> IMO, these dependencies should stay as the project is trying hard to move
> towards rule updates instead of engine updates.  Additionally, the spec file
> should likely be running sa-update to install the rules from a local tar
> instead of reverse engineering the proper location.

+1

(In reply to comment #3)
> IMO, these dependencies should stay as the project is trying hard to move
> towards rule updates instead of engine updates.  Additionally, the spec file
> should likely be running sa-update to install the rules from a local tar
> instead of reverse engineering the proper location.

In that case, IO::Zlib should be a mandatory dependency instead of being optional (sa-update requires it).

(In reply to comment #5)
> (In reply to comment #3)
> > IMO, these dependencies should stay as the project is trying hard to move
> > towards rule updates instead of engine updates.  Additionally, the spec file
> > should likely be running sa-update to install the rules from a local tar
> > instead of reverse engineering the proper location.
> 
> In that case, IO::Zlib should be a mandatory dependency instead of being
> optional (sa-update requires it).

I agree. +1 to making IO::Zlib a dependency and keeping Archive::Tar a requirement as well.

(In reply to comment #2)
> Not necessarily.
> 
> Eg, the Fedora RPM SPEC file just untar's the rules into place.

Fedora's RPM now sa-update by default on a nightly basis.  sa-update is no longer optional.

+1 to making both Archive::Tar and IO::Zlib hard requirements.

(In reply to comment #7)
> Fedora's RPM now sa-update by default on a nightly basis.  sa-update is no
> longer optional.

Aplogize for hijacking this bug...

I truly hope you're not hammering the donated sa-updates servers with this and that RedHat uses its own sa-update server.

(In reply to comment #8)
> (In reply to comment #7)
> > Fedora's RPM now sa-update by default on a nightly basis.  sa-update is no
> > longer optional.
> 
> Aplogize for hijacking this bug...
> 
> I truly hope you're not hammering the donated sa-updates servers with this and
> that RedHat uses its own sa-update server.

Mitigating factors:
* It skips sa-update if spamd or amavisd is not running, and we don't run spamd by default if you have the packaged installed.
* It also delays a random amount of time before doing it, so it wont bog down the server with requests all at the same moment.

Is this still too much?

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > Fedora's RPM now sa-update by default on a nightly basis.  sa-update is no
> > > longer optional.
> > 
> > Aplogize for hijacking this bug...
> > 
> > I truly hope you're not hammering the donated sa-updates servers with this and
> > that RedHat uses its own sa-update server.
> 
> Mitigating factors:
> * It skips sa-update if spamd or amavisd is not running, and we don't run spamd
> by default if you have the packaged installed.
> * It also delays a random amount of time before doing it, so it wont bog down
> the server with requests all at the same moment.
> 
> Is this still too much?

for default setups, once a week would be more than enough.
"dedicated" admins can tweak, most won't
imo, ideally, distros which enable sa-update by default should provide resources to cover the load they're adding.
I imagine this auto sa-update could also land in mainstream RHE / Centos etc, the load added can become... HUGE, plus the pressure put on donated time to run the stuff to keep an even larger user base happy.

Honestly, don't think its a good idea to enable sa-update by default. Dunno what others think....especially the ones supplying the sa-update infrastructure.

Comments?

> Honestly, don't think its a good idea to enable sa-update by default. Dunno
> what others think....especially the ones supplying the sa-update
> infrastructure.

I think it's a good idea but I *thought* sa-update checked DNS for the availability of an update not an http query.
KAM

(In reply to comment #11)
> > Honestly, don't think its a good idea to enable sa-update by default. Dunno
> > what others think....especially the ones supplying the sa-update
> > infrastructure.
> 
> I think it's a good idea but I *thought* sa-update checked DNS for the
> availability of an update not an http query.
> KAM

yes.. it does.. DNS traffic is also traffic. I wouldn't underestimate it.

(In reply to comment #11)
> > Honestly, don't think its a good idea to enable sa-update by default. Dunno
> > what others think....especially the ones supplying the sa-update
> > infrastructure.
> 
> I think it's a good idea but I *thought* sa-update checked DNS for the
> availability of an update not an http query.
> KAM

yep it does.  I'm quite happy to see sa-update enabled by default, to be honest; if we need more mirrors, we need more mirrors, and that's easily done.  in the meantime sa-update will do the right thing, retry where necessary, etc.

at some point we should do the "random offset from hour" thing ourselves, but the right way (as per my coworker Colm):
http://www.stdlib.net/~colmmacc/2009/09/14/period-pain/
http://www.stdlib.net/~colmmacc/2009/09/27/period-pain-part-2/

http://cvs.fedoraproject.org/viewvc/devel/spamassassin/sa-update.cronscript?revision=1.7&view=co

Here is the script we run from cron by default as of 3.3.0.

* Looks for daemons and runs sa-update only if it sees a running daemon.
* Random delay up to 2 hours.
* .d directory to specify arbitrary channels in separate files, makes it easy to add/remove channels automatically using packages later.
* Restarts the appropriate daemon after successful sa-update.

Carrying over the discussion on how/when users should run their sa-update
onto Bug 6281.

Created attachment 4630 [details]
proposed patch

(In reply to comment #6)
> I agree. +1 to making IO::Zlib a dependency and keeping Archive::Tar a
> requirement as well.

(In reply to comment #7)
> +1 to making both Archive::Tar and IO::Zlib hard requirements.

(In reply to comment #16)
> Created an attachment (id=4630) [details]
> proposed patch
> 
> (In reply to comment #6)
> > I agree. +1 to making IO::Zlib a dependency and keeping Archive::Tar a
> > requirement as well.
> 
> (In reply to comment #7)
> > +1 to making both Archive::Tar and IO::Zlib hard requirements.

+1 KAM to the patch to mchange the DependencyInfo MakeFile and release text making IO:Zlib required and closing the "bug" that archive::tar was required.

+1

Bug 6265: Archive::Tar and IO::Zlib should be required by spamassassin
Sending        Makefile.PL
Sending        build/announcements/3.3.0-release.txt
Sending        lib/Mail/SpamAssassin/Util/DependencyInfo.pm
Transmitting file data ...
Committed revision 897930.