http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5147
------- Additional Comments From [EMAIL PROTECTED] 2006-10-27 08:45 ------- (In reply to comment #7) > Daryl's right -- that won't do the trick. Here's another, worse, problem > case: > consider what'll happen the day a release is made; the update will contain > data > predating the release. > In other words it's *impossible* to run sa-update on that day without > installing an invalid ruleset ;) I had dev versions in mind since (i) at least 24 hours should pass between the time a release tarball is made and the time it's released if we're actually waiting long enough for problems to be spotted with the release; and (ii) updates for the stable branch are down manually, so even though it's not in the release procedure (it should be), whoever cuts a release needs to make sure that current update isn't going to screw up the new release and make a new update if necessary. So really, (ii) applies now and (i) applies if we get things automated later. > Comparing modification dates seems to be the best option, in my opinion. It's > a trivial tweak to the algorithm: change sa-update to touch(1) the update dir > each time it downloads an update; then when Mail::SpamAssassin is looking for > rule-updates, if the modtime of /var/lib/spamassassin is older than > /usr/share/spamassassin, ignore the update and use the latter instead. Doesn't work either. Starting with nothing... - install dev version with rules in /usr/share/spamassassin - run sa-update and get older version of rules than in /usr/share/spamassassin - sa-update touches /var/lib/spamassassin with date newer than /usr/share/... - we end up using the older rules in /var/lib/spamassassin because they have the latest mtime ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
