[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: possible mass bug filing: spamassassin 3

Tollef Fog Heen [u] wrote on 07/10/2004 10:00:

* Sven Mueller
| Well, perl modules don't have an SO name.

: tfheen@vawad /usr/lib > apt-cache show libvideo-capture-v4l-perl| grep ^Depends
Depends: perlapi-5.8.3, perl (>= 5.8.3-2), libc6 (>= 2.3.2.ds1-4)

Seems like perl provides an API that the module depends on, no?

perlapi seems to be some sort of a pseudo package. But anyway: What does a package version have to do with SO names?

| And actually, the "library" part of SA isn't intended to be the most
| often used one.

If it is provided, it must work.

So if someone provides a huge program which consists of various specially crafted dynamic libraries (whose APIs are documented but not really intended for use outside of this specific program), these libraries may not change in a way which changes those APIs?
Sure seems strange to me.
The only official interfaces SpamAssassin ever provided (to the best of my knowledge) are:
1) calling spamassassin directly (as a commandline tool)
2) calling the spamc client (again, as a commandline tool)
3) accessing spamd over its defined interface (which is used by spamc)

> If it is changed in an incompatible fashion, it must bump soname.
> Or make SA into a library proper, with
libmail-spamassassin-perl being the module part and spamassassin
depending on that.

Well, in that case, libmail-spamassassin-perl would be the size of the current spamassassin package, and the new spamassassin package (which depends on the libmail-spamassassin-perl package) is about 2k in size, description and packaging overhead included. Sorry, that doesn't make much sense.

> You'd still have to bump soname, but only for the
library part.

Go learn perl, than come back. Perl Modules might have version numbers, but they certainly don't have SO names. BTW: Give a descend definition of what you refer to as soname, and I might apologize and say that you are right. But for now we either have different ideas of what a soname is or you don't have much knowledge about perl (heck, I don't know perl well, but I know enough to be certain that perl modules don't have anything I would call a soname).

This is _not_ hard to get right, and there is really no exuse not get
it right.

The only way to get it right (in your sense of the word) would be to rename the Perl Mail::SpamAssassin module (along with its sub-modules) to Mail::SpamAssassin3. However, this would make some programs break which are otherwise able to cope with v3 Mail:SpamAssasin quite well.

spampd for example has a total of 10 lines which differentiate between versions v being < 2.7, 2.7 <= v < 3.0 and v >= 3.0 _and_ do what's needed to work with either of the three possible categories of SpamAssassin versions. If SpamAssasin v3 would be renamed to Mail::SpamAssassin3, the changes would be more like 120 lines.

And given the fact that the SA3 API has been published more than 7 month ago (more like 8: 2004-02-18 was the last date on which the API was changed in an incompatible way), each tool had more than enough time to adjust to this. Note: The outside API (i.e. the API to _use_ SpamAssassin as opposed to the inside API used to enhance SpamAssassin by plugins) only had pretty minor changes.


Reply to: