bogofilter-static-1.0.0-1 RPM problem (CentOS 3.6)

[Matthias Andree]

David Relson <relson at osagesoftware.com> writes:

>> What processor is this on?  Also what version of DB4?
>> 
>> I ask as had some NPTL problems on an AMD K6 with the default db4 rpm,
>> issue (poorly) outlined here:
>>   http://thread.gmane.org/gmane.mail.bogofilter.general/8305
>> and see this bug related to NPTL (not sure if this is your issue):
>>   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91933
>> 
>> Chris
>
> Al & Chris,
>
> My static rpm was built with BerkeleyDB 4.2.52.  Using "ls -l" gives
> the following info for the rpm and the files it installs..

What Chris is saying is that although the executable may have been
linked statically, it may still have inherited dependencies on the
processor type, mutex support or kernel of the build machine through the
statically linked Mandrake Berkeley DB.

Remember the problem that transactions wouldn't work on some
Fedora/processor combinations because only private environments were
supported?  I have forgotten the details, the grand picture was that
their Berkeley DB had compiled NPTL (next-generation POSIX thread
library) stuff in, which worked only for the latest processor
generation.

We need to solve the original problem though; I see these ways out:

A. 1. build a Berkeley DB 4.2 RPM that installs libdb-4.2.so in the default
   shared library search path (usually /usr/lib on Linux).

   2. make sure the OS has GNU libc 2.3.4 or newer installed.

   3. install the shared-library version

B. 1. install a suitable Berkeley DB for your system (bogofilter copes
   with 3.1, 3.2, 3.3, 4.0, 4.1, 4.2, 4.3, 4.4 and recommends 4.1 or
   later, personally, I'd use 4.2 or newer though)

   2. use rpmbuild --rebuild on the official *.src.rpm.

You'll have to use B for x86_64, ppc, sparc and sparc64 anyways.

I haven't checked yet if LSB mentions anything WRT Berkeley DB that we
could exploit to enhance compatibility.


On a personal note, and this is distinctly *not* the official bogofilter
team opinion: I have been against a convenience package such as
bogofilter_static. Linking statically means more memory use, more
efforts to upgrade should a relevant bug in Berkeley DB be found and
fixed (since bogofilter_static will have to be rebuilt and reinstalled,
too), and evidently it doesn't resolve problems as far as we'd wish it
would.  The motivation was to offer a binary RPM for people to try if their
system has a different Berkeley DB package installed, when instead the
system should have provided at least a compatibility package (SUSE do,
db42, and it has regular and thread-local-store variants in /usr/lib and
/usr/lib/tls). (Personal note ends here.)


Now that we've had the _static packages in 1.0.0, every future 1.0.X
version will have to offer them for compatibility, but we cannot
possibly guarantee that it works on every system.

AFAIK, the pkgsrc project of NetBSD fame has been ported and works on
Linux, Solaris and other systems. So pkgsrc can also be used to build a
bogofilter version (currently 0.96.6, supporting db4.3.29 or
sqlite3.2.7) which may help building a local version, all dependencies
will be resolved automatically within pkgsrc.

-- 
Matthias Andree