You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by ji...@jidanni.org on 2008/02/06 05:32:10 UTC
upgrading is just like installing
Let's record my 3.23 to 3.24 upgrade attempt.
I untar Mail-SpamAssassin-3.2.4 and of course read the file entitled
UPGRADE.
In it I find "Note for Users Upgrading to SpamAssassin 3.2.0".
But I am upgrading to 3.24.
Go ahead and call me dumb, but if I mess up, I might endanger my
email.
Now I look in README. No, no instructions there.
OK, now looking at INSTALL
Upgrading SpamAssassin?
-----------------------
Please be sure to read the UPGRADE file for important changes that
have been made since previous versions.
Installing or Upgrading SpamAssassin
------------------------------------
OK, looks like I am on the right track. (I recall upgrading MediaWiki
was more intuitive.)
OK, now after reading the whole INSTALL file, I come to the conclusion
that to upgrade, one just acts like one never installed SpamAssassin
in the first place, and apparently the new SpamAssassin will just
install on top of the old one (with cruft surely accumulating in the
corners, I bet.)
OK... it all worked out. I even remembered to do sa-update, a step
mentioned in here in the newsgroup, not in the highly cluttered
INSTALL file.
OK, see you back here when 3.25 comes around, as I don't remember anything.
RE: upgrading is just like installing
Posted by "James E. Pratt" <jp...@norwich.edu>.
-----Original Message-----
From: jidanni@jidanni.org [mailto:jidanni@jidanni.org]
Sent: Tuesday, February 12, 2008 3:26 PM
To: users@spamassassin.apache.org
Subject: Re: upgrading is just like installing
KB> User? SA is for administrators, not for users. Also, there is
*nothing*
KB> special about SA version numbers.
J> Is too or else there wouldn't be a user_prefs file or instructions
for
J> installing non-root. And SA version numbers & aliases often need
explaining,
J> just like Debian package version numbers etc. Not all software
version
J> number systems are the same or else there would be several ways to
enter a
J> decimal password OK never mind.
----
Ummm .. sa version numbers? Aliases? Decimal passwords? Package
explanations? .... HUH?
(I think you are on the wrong list, or have to go back to school or
something(?)
Anyhow, yes , the user_prefs files are for user-based settings, but you
are missing too many points for me to continue as it's just too silly to
add more to the thread! :P
cheers,
jamie
Re: upgrading is just like installing
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Wed, 2008-02-13 at 04:25 +0800, jidanni@jidanni.org wrote:
> KB> User? SA is for administrators, not for users. Also, there is *nothing*
> KB> special about SA version numbers.
> Is too or else there wouldn't be a user_prefs file [...]
Then stick to the user_prefs file.
You do realize there is a fundamental difference between those user
preferences in your home (after the fact of installation, mind you) on
one hand, and installing and administration of a system wide service
like SA and integration with the MTA infrastructure on the other hand?
You just don't get it. And frankly, if you don't understand the version
numbers of the software you are about to install from source -- don't.
Use your distro provided packages. 'nuff said.
guenther
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: upgrading is just like installing
Posted by ji...@jidanni.org.
KB> User? SA is for administrators, not for users. Also, there is *nothing*
KB> special about SA version numbers.
Is too or else there wouldn't be a user_prefs file or instructions for
installing non-root. And SA version numbers & aliases often need explaining,
just like Debian package version numbers etc. Not all software version
number systems are the same or else there would be several ways to enter a
decimal password OK never mind.
Re: upgrading is just like installing
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Sun, 2008-02-10 at 05:12 +0800, jidanni@jidanni.org wrote:
> KB> No, you are not. Please note that these are version numbers, not floats.
> KB> With respect to minor versions, 24 is massively larger than 2...
>
> It's all a usability (http://www.useit.com/alertbox/) problem. You
> might say SpamAssassin is usability exempt, as it is only for computer
> pros. But I'm here to give valuable insights of how SpamAssassin looks
> to we lesser programmers. Just want to let you know. Can't help. Gotta go.
If you don't understand version numbers, and the difference to floats,
you seriously should not build from source. Back in school you learned
that there is only one decimal point in floats, right?
> Anyway, assuming the user guesses correctly the special world of
> SpamAssassin version numbers, the UPGRADE file still doesn't mention
> anything beyond 3.2.0.
User? SA is for administrators, not for users. Also, there is *nothing*
special about SA version numbers.
Anyway, if you still don't understand how to read the UPGRADE file,
seriously, don't. Install from packages, but don't touch the source.
guenther
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: upgrading is just like installing
Posted by ji...@jidanni.org.
KB> No, you are not. Please note that these are version numbers, not floats.
KB> With respect to minor versions, 24 is massively larger than 2...
It's all a usability (http://www.useit.com/alertbox/) problem. You
might say SpamAssassin is usability exempt, as it is only for computer
pros. But I'm here to give valuable insights of how SpamAssassin looks
to we lesser programmers. Just want to let you know. Can't help. Gotta go.
Anyway, assuming the user guesses correctly the special world of
SpamAssassin version numbers, the UPGRADE file still doesn't mention
anything beyond 3.2.0.
KB> Anyway, the UPGRADE file and its information is targeted at upgrading
KB> minor (or even major versions). Read, when upgrading from 3.1.x (or
KB> older) to 3.2.x for example. It mentions incompatibilities or general
KB> issues that may need attention when doing such an upgrade.
KB> Generally, no such issues exist when upgrading micro versions. Which you
KB> in fact did.
So it should mention all that. Or better yet see how MediaWiki
packages their upgrade instructions.
KB> However, you likely just overwrote your changes to local.cf
Naw, else it wouldn't say
$ head ~/etc/mail/spamassassin/local.cf
# This is the right place to customize your installation of SpamAssassin.
KD> This is why I don't often install from source.
I would but Dreamhost's Debian is too "stable" for me to run my brilliant
http://jidanni.org/comp/spam/spamdealer.html "filter on the server"
solution whilst enjoying the latest SpamAssassin.
Re: upgrading is just like installing
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Wed, 2008-02-06 at 12:32 +0800, jidanni@jidanni.org wrote:
> Let's record my 3.23 to 3.24 upgrade attempt.
>
> I untar Mail-SpamAssassin-3.2.4 and of course read the file entitled
> UPGRADE.
>
> In it I find "Note for Users Upgrading to SpamAssassin 3.2.0".
> But I am upgrading to 3.24.
No, you are not. Please note that these are version numbers, not floats.
With respect to minor versions, 24 is massively larger than 2...
Anyway, the UPGRADE file and its information is targeted at upgrading
minor (or even major versions). Read, when upgrading from 3.1.x (or
older) to 3.2.x for example. It mentions incompatibilities or general
issues that may need attention when doing such an upgrade.
Generally, no such issues exist when upgrading micro versions. Which you
in fact did.
> OK, now after reading the whole INSTALL file, I come to the conclusion
> that to upgrade, one just acts like one never installed SpamAssassin
> in the first place, and apparently the new SpamAssassin will just
> install on top of the old one (with cruft surely accumulating in the
> corners, I bet.)
Unless your configure or build options change, there should be no cruft.
However, you likely just overwrote your changes to local.cf and friends,
if any.
> OK... it all worked out. I even remembered to do sa-update, a step
> mentioned in here in the newsgroup, not in the highly cluttered
> INSTALL file.
I guess that is, because it is entirely optional. You do not need to
sa-update, when installing.
guenther
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: upgrading is just like installing
Posted by Kris Deugau <kd...@vianet.ca>.
jidanni@jidanni.org wrote:
> OK, now after reading the whole INSTALL file, I come to the conclusion
> that to upgrade, one just acts like one never installed SpamAssassin
> in the first place, and apparently the new SpamAssassin will just
> install on top of the old one (with cruft surely accumulating in the
> corners, I bet.)
This is why I don't often install from source. I install distribution
packages, third-party packages, or my own local packages (in that order
of priority). There's also the slight issue of keeping the build
process as identical as possible between systems if you're installing on
a cluster of some kind.
Things still get a little messy around the edges after a couple of
years, but packaged software reduces that by quite a bit IME.
On the SA cluster at head office, I've taken a slightly different tack;
I wrote a couple of short shell scripts to ease SA upgrades. (Those
scripts, incidentally, are packaged locally. <g>)
One snags the tarball and installs it to a unique location based on the
version number it's passed as a command line argument.
The other rearranges symlinks and restarts SA to switch the running
versions.
I'm still left to make sure the full config gets copied over from the
current install to the new one, but that also *forces* me to review any
customizations I've made. For instance, we disabled a couple of RBLs a
few releases back because they started triggering on everything, and the
release we're running has those removed completely - no point in keeping
the "score BADRBL 0" lines around.
-kgd