SA Bugzilla – Bug 1341
Improve packageability of libspamc
Last modified: 2024-03-25 19:27:48 UTC
The Debian packages at http://people.debian.org/~duncf/debian/ and also the debian/ directory in CVS dont build or package libspamc. I had a look at hacking in some rules to make & package libspamc but I dont know enough about the Debian packaging stuff to make it work properly.
This type of bug (i.e. specifically related to Debian packaging) needs to be filed in the Debian BTS. (file against the package spamassassin) I don't see myself fixing this soon... but I suppose eventually I should get around to it. Closing INVALID, not because the bug is INVALID, but rather this is the wrong place to report it.
The is not a Debian problem. The installer in the SpamAssassin package does not install the library in a directory like {prefix}/lib. So it is not included in the Debian package. I have created a little patch to add this ability to the configure script and the binaries.mk Makefile. You need the scripts "install-sh" and "mkinstalldirs" from the automake package for it (just copy them to the directory where configure is located). Then you have to run aclocal autoconf ./configure make -f binaries.mk install This will install the library (libspamc.so) and the header file (libspamc.h) in the correct location. I did not understand the Makefile.PL stuff to add it there. But I'm sure the SpamAssassin developers could add it and it would be good if this ability could be added to the SpamAsssassin package.
Created attachment 1215 [details] Add install rule to binaries.mk and required stuff to configure
I'm interested in this. There is a libspamc$(SHLIBEXT) target in spamc/ Makefile.in, but it's not used. What were the original plans for this? Having a shared spamc library makes it easier to integrate various spplications with SpamAssassin.
Created attachment 3885 [details] Let libspamc tell spamc whether it's compiled with SSL support Here is one thing I think is needed to decouple libspamc from spamc. Since there is no SSL-related code at all in spamc.c, except for the version information and option parsing, I think spamc should ask libspamc whether it is compiled with SSL support. This gives many options: spamc can still be compiled with libspamc statically, or it can be compiled dynamically. In the latter case, one can choose to link with either libspamc or libsslspamc, or both versions (with or without SSL support) can be called libspamc, and the administrator can switch between them without rebuilding the spamc binary.
So, please reopen, set severity to enhancement and change the summary to "Please make libspamc packageable" or something like that.
Looks like this should have been reopened a while ago... Oops.
Pushing to future as an enhancement Christoph and Magnus, can you please file a CLA for your patches? https://www.apache.org/licenses/