On Mon, 05 Nov 2007, Martin Zobel-Helas wrote:
> spamassassin 3.2.3-0.volatile1 is currently available in
> etch-proposed/volatile. Before we accept it to etch/volatile i would
> like to ask some experienced SysAdmins to do some (more extended testing
> as we did) of the package and report back any problems you find to
> debian-volatile@lists.debian.org.
>
> As soon as we are convinced that SA 3.2.3 works as expected i will
> move the package to etch/volatile and send an official announcement.
I wonder if spamassassin is volatile material? It certainly fits
backports.org (and I use the backport on production), but I have always
thought of volatile as something with exactly the same importance and
connotation as main.
Which means that, should a volatile spamassassin upgrade change ABIs, we
would also need to update amavisd-new, and anything else that links directly
to spamassassin perl modules...
It would feel weird to have amavisd-new in volatile. And it would be
extremely wrong to have anything in volatile *break* it and NOT have an
updated one available in volatile, so we would have to, should it happen.
The same is valid for any other package.
IMO, it is best to leave stuff like spamassassin out of volatile.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh