Spamassassin delta review summary
And a quick 75,000 lines of eye glazing perl later ...
My first note is that the packaging appears to have dropped debconf
support altogether. I am not unhappy about that (it didn't really need
it to begin with) but it represents a packaging change, and so should be
noted.
Razor and DCC are now disabled by default. This is, again, probably the
right change, since there are issues with using them non-commercially, but
it represents a (potentially significant) change. It looks like upstream
has split them (as well as significant parts of other functionality (AWL,
spamcop reporting, etc) out into modules that are disabled by default
(as opposed to the old 'use if installed' mode), and they will need to
be specifically enabled in order to keep the same arrangement as people
may have had before.
Several of the modules have a changed API. This should not matter, since
the SA documentation says that the internal API should not be used in
user scripts, as it is subject to rapid change and will break frequently.
But, it is a change so I thought it should be mentioned.
Several configuration options have changed. This applies to both
command line options for the programs, and to configuration options (both
system wide, and for user_pref type stuff). These are for the most part
options that were already deprecated in sarge, but were still allowed.
This strikes me as the biggest problem. As a balancing point, since
this applies to user preferences as well (and SA appears to do the sane
thing and just carry on after spitting out a warning), I think that
there probably is no package level upgrade path here. We can't expect
SA to mangle user home directories at upgrade (IMHO).
So, I see one package change that matters (although not much) and two
upstream issues that affect the upgrade path. Since both of these are
issues that can only be fully dealt with by
a) first, figuring out where user prefs are stored ($HOME, SQL, etc)
b) munge the user data
c) munge the system wide configs
I think a packaged upgrade solution is fragile at best, and probably
best avoided. That is the decision I would take if I were maintaining SA,
at any rate. I do think it appropriate to slap in a giant README.Debian
that says 'Your config may be b0rked by this upgrade. Read the upgrade
notes NOW'. I also think a warning of this type would be appropriate
in the VUA as well, should this package be accepted.
Speaking for myself, I would love to see a community supported newer
version of SA available for the servers I admin. I do see some upgrade
issues that make me a little leery, though, so I am trying to present
a balanced report of all the things I see that may be problems.
Hope that is helpful, and if there are any questions (or glaring
mistakes/omissions/thinkos) please let me know.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Reply to: