Scripsit Colin Watson <[EMAIL PROTECTED]>
> This is backwards. The conflicts must be added in spamassassin in order
> that we don't forget to remove said other packages from sarge if
> necessary.
Won't work, at least not by itself. Since we expect the other packages
to sooner or later be updated to work with spamassassin3, a conflict
from spamassassin would need to be a versioned one. But how is the
spamassassin maintainer to know which future version of the client
package will work with spamassassin3?
The only fully watertight solution would be to have spamassassin 3
declare
Conflicts: client-package-1 (<= $currentversion1),
client-package-2 (<= $currentversion2),
...
client-package-N (<= $currentversionN)
and arrange for *each* *future* version of the client packages to
declare
Conflicts: spamassassin (>= 3.0)
until they have been fixed.
(But release-manager intervention would still be needed for SA3 to
proceed to testing before all current clients have been fixed).
--
Henning Makholm "The compile-time type checker for this
language has proved to be a valuable filter which
traps a significant proportion of programming errors."
