On Tue, 8 Aug 2006, Bret Miller wrote:
I'm not exactly sure what the thinking was in moving the updates to /var/lib instead of keeping them with /usr/share with the original rules. I wonder why sa-update doesn't just create a version folder under /share/spamassassin and use that...
Because it's bad form, at least according to some people, to write mutable data into the software install directory. This isn't as common as it used to be, but at one time, some people would mount /usr as a separate filesystem and make it read-only. Since all the data was written into /var, there was no reason for /usr to be read-write if you weren't installing or updating software. Similarly, some sites have a great big shared /usr/local that is NFS-mounted across many machines. The clients aren't supposed to write there because they don't own it and could potentially screw it up for other systems sharing the same /usr/local. In fact, in some cases, /usr/local can be mounted from any one of several servers and updated copies are pushed from the master /usr/local to the other servers' /usr/local. The general idea is that software and its data should be separated so that you can run multiple instances of the software without having multiple copies of the constant parts of it or so that you can put one in a read-only location and the other in a read-write location. Now, is this directly applicable to SpamAssassin? Well, on a dedicated mail server that uses SpamAssassin as a plugin, it's probably not. You are going to have exactly one set of rules and exactly one SA install. But one could envision several users on a machine sharing the same install of it. Maybe the users all fetch mail from other servers and run their own instances of SpamAssassin through procmail or something. Also, even if it isn't relevant for SpamAssassin in particular, it's part of the idiom for installing software on Unix in general, so it is might be logical to install it that way just for the sake of consistency. - Logan
