http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5147
------- Additional Comments From [EMAIL PROTECTED] 2006-10-27 06:24 -------
> The issue is: what is r123456 ? The version of sa-update? Only changes when
> sa-update changes. The dev version in M::SA? Only changes when M::SA is
> updated. Checked out revision you built from? Would require kluges to work
> (likely the same type of kluges as our nightly/weekly runs do).
OK, good point.
> I still think the already suggested behavior of running sa-update after doing
> an
> install/upgrade is the best solution.
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.
To illustrate in more detail, here's the current problem case:
- 1. user downloads a dev, prerelease tarball of 3.2.0, installs it
- 2. runs sa-update, gets rules version N
- 3. next day, 3.2.0 is released, containing rules version N+1
- 4. on that same day, user downloads, installs it
- 5. /var/lib/spamassassin/3.002000/updates_spamassassin_org (version N) is
used, instead of /usr/share/spamassassin (version N+1)
so let's say the user rm's the update dir and calls sa-update after install:
- 1. user downloads a dev, prerelease tarball of 3.2.0, installs it
- 2. runs sa-update, gets rules version N
- 3. next day, 3.2.0 is released, containing rules version N+1
- 4. on that same day, user downloads, installs it
- 5. "rm /var/lib/spamassassin/3.002000; sa-update"
- 6. sa-update downloads and installs rules version N _again_!
- 7. /var/lib/spamassassin/3.002000/updates_spamassassin_org (version N) is
used, instead of /usr/share/spamassassin (version N+1)
In other words it's *impossible* to run sa-update on that day without
installing an invalid ruleset ;)
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.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
