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

Re: possible mass bug filing: spamassassin 3

* Sven Mueller 

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

It's a virtual package.

| But anyway: What does a package version have to do with SO names?

(I assume you meant package name, if not please explain a bit further
what you mean)

For packages including APIs, the package name should include the API
version number.  For shared objects (libraries), that's the soname.
Perl modules don't really have a similar concept, but that's just
tradition and there's no reason why they couldn't.

| > | 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?

Yes, or rather it must bump the soname when changing those APIs.

Also, if they're not intended for general use, they shouldn't be put
in /usr/share/perl5 but in a private module directory.  (Similarly,
not /usr/lib for private libraries, but a /usr/lib/$packagename/ or
something like that.)

| 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)

>From the front page of spamassassin.org:

: Flexible: SpamAssassin encapsulates its logic in a well-designed,
: abstract API so it can be integrated anywhere in the email
: stream. The Mail::SpamAssassin classes can be used on a wide variety
: of email systems including procmail, sendmail, Postfix, qmail, and
: many others.

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

: tfheen@yiwaz ~ > for f in $(dpkg -L spamassassin | grep -v perl \
  |grep -v man3 ); do [ -f $f ] && echo $f; done | xargs du -shc  |
  tail -1
1,1M    totalt

SA currently ships nearly 600k of rules.

| > You'd still have to bump soname, but only for the library part.
| Go learn perl, than come back.

(Apology about writing mail after discussion with boss accepted. :)

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

soname is here used a bit loosely meaning «ABI/API version»; this is
technically not correct (as you point out), but it's shorter than
writing «ABI/API version» all over the place.

(And, given that perl modules can be normal shared objects, they
certainly _can_ have sonames proper, but I agree that's not the norm.)

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

They can try to import Mail::SpamAssassin3 first, if that fails, try
Mail::SpamAssassin.  A nice thing with this is you actually know what
API you use.

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

      eval {
           require Mail::SpamAssassin3;
           import Mail::SpamAssassin3 qw(foo bar baz);
      if ($@) {
         require Mail::SpamAssassin;
         import Mail::SpamAssassin qw(foo bar baz);

Doesn't look like 120 lines to me.

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

This is orthagonal to the discussion -- how much and when the API
changed doesn't mean it shouldn't be done right.

This is Debian.  We don't break stuff arbitrarily.  If you have a
package which breaks packages depending on you, it's a bug in your
package (with exceptions if a package is tinkering with some private
functionality in your package or taking advantage of a bug or
undefined behaviour in your package).  It's very easy to fix that bug,
though:  Conflict with the packages you break.

Tollef Fog Heen                                                        ,''`.
UNIX is user friendly, it's just picky about who its friends are      : :' :
                                                                      `. `' 

Reply to: