Re: possible mass bug filing: spamassassin 3

[Henning Makholm <henning@makholm.net>]

Scripsit Colin Watson <cjwatson@debian.org>

> 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."