Duncan Findlay writes: > On Wed, Dec 14, 2005 at 04:54:54PM -0800, Justin Mason wrote: > > So we have these requirements: > > > > 1. use /var for updates, instead of /etc or /usr > > > > 2. sa-update updates must not overwrite any packaged files > > > > 3. the user shouldn't have to choose at package-install time whether > > they want to use packaged rules, or sa-update rules. (although > > conversely, it's ok to entirely stop using packaged rules from that > > point on, if sa-update installs an update set.) > > Agreed. > > > So the suggestion is to use: > > > > /etc/mail/spamassassin: > > > > *.cf > > *.pre: Admin-installed local settings > > > > > > /usr/share/spamassassin: > > > > default, distro-package-installed scores and rules > > > > > > /var/lib/spamassassin/3.1.0: > > /var/lib/spamassassin/3.1.1: > > /var/lib/spamassassin/3.1.2: > > /var/lib/spamassassin/3.2.0: > > > > sa-update-installed scores and rules > > I'm not sure I see the need for multiple directories lying around. I > suppose it can be useful, I'm assuming that most will only have one > directory. Also, sa-update should be smart enough to remove old > directories of previous versions (optionally?).
The use-case that this helps with, is: - user of 3.1.1 runs "sa-update" - sa-update downloads replacement ruleset into /var/lib/spamassassin - SpamAssassin.pm ignores /usr/share/spamassassin in favour of /var/lib/spamassassin - user later upgrades to 3.1.2 - SpamAssassin.pm still ignores /usr/share/spamassassin in favour of /var/lib/spamassassin, hence attempts to use the now-obsolete /var/lib/spamassassin ruleset (at least until sa-update is run again). If we version the /var/lib/spamassassin directory, then we would have this timeline: - user of 3.1.1 runs "sa-update" - sa-update downloads replacement ruleset into /var/lib/spamassassin/3.1.1 - SpamAssassin.pm ignores /usr/share/spamassassin in favour of /var/lib/spamassassin/3.1.1 - user later upgrades to 3.1.2 - SpamAssassin.pm finds no /var/lib/spamassassin/3.1.2 , so uses /usr/share/spamassassin - (at least until the user runs sa-update again and creates /var/lib/spamassassin/3.1.2) > > The presence of anything in /var/lib/spamassassin/3.1.1 causes > > /usr/share/spamassassin to be ignored. > > > > All rules, including the code-tied stuff for that release, are put in the > > sa-update tarballs (and therefore /var/lib/spamassassin/3.1.2 etc.) > > Hmm... does it make sense to redistibute the code-tied stuff? That > seems like unnecessary bandwidth usage. sa-update should only be > grabbing the "changing" non-code tied stuff. I'd prefer to avoid it, but *not* distributing the code-tied stuff would require we differentiate them here, and that's proved tricky. Another option, down the line, is to do some smart delta-based download system, which would help too if rules don't change between sa-update updates. Again, not implemented yet. --j.
