Re: possible mass bug filing: spamassassin 3
Steinar H. Gunderson [u] wrote on 06/10/2004 22:37:
>> On Wed, Oct 06, 2004 at 09:10:39PM +0200, Sven Mueller wrote:
>>
>
>>>>??? Since when does exim4 use SA by default? AFAIK, you have to
>>>>specifically configure it to use it. Right? If so, there should be no
>>>>reason to remove it or for it to conflict with SA3.
>
>>
>> Well, if I dist-upgrade my mail server so a new spamassassin comes
in, my
>> mail setup breaks. Now, that is clearly broken, and an RC bug on some
>> package.
If it were happening in stable, I am 100% with you.
It it is with regards to testing, well, I'm between 30% and 70% with
you. More on 60% currently with the release pending any month now ;-)
With regards to unstable, I'm more like 10% with you on this matter.
If it is possible for a maintainer to avoid such breakages, he should
100% do that. But with spamassassin, I don't really see how the
maintainer should do that. Many frontends work with the new spamassassin
with no change at all, and those would certainly like to benefit from
SA3 without needing to change their packages. Many other frontends
break. But how should the SA maintainer know which frontends break and
which don't? He would only want to Conflict with those that break,
leaving the others alone.
>>>>If a program is a front-end for SA and only works if SA is installed,
>>>>then it should keep up with any changes SA is doing to its API.
>
>>
>> Wrong. SA should not change its API in an incompatible fashion
without also
>> bumping its soname (ie. the package name in this case), like any
other library.
Well, perl modules don't have an SO name. And actually, the "library"
part of SA isn't intended to be the most often used one. More
specifically, the spamassassin has always stated that though they try to
keep the API, it is not guaranteed to be compatible from one revision
(sic!) to another. The only part that was guaranteed to maintain their
interfaces for at least major 1 version (obsoleting but still supporting
in 3.x what was supported in 2.x) where the "executables" spamassassin,
sa-learn, spamc, spamd.
>>>>And SA3 API isn't _that_ much different from SA2.6 API for the most
used
>>>>interfaces.
>
>>
>> In that case, it should provide a backwards-compatible interface.
Well, they could probably do that for many parts (the most often used
ones, actually), but I doubt that it is possible for all parts.
cu,
sven
Reply to: