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.
Regards,
Sven
Reply to: