* Sven Mueller
| Tollef Fog Heen [u] wrote on 07/10/2004 10:00:
|
| > * Sven Mueller | Well, perl modules don't have an SO name.
| > : [EMAIL PROTECTED] /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.
: [EMAIL PROTECTED] ~ > 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.
BEGIN {
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 : :' :
`. `'
`-
