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

[bogo at escom.com]

Since I've been the cause of a lot of traffic on this list recently,
I wanted to clarify why I'm asking all these bizarre questions,
and why it may seem that I can't make up my mind what version of 
Linux I want to run.

The reason is that I'm asking mostly on behalf of ESCOM's customers,
of which more than half have Windows backgrounds, and who may be
running anything from Red Hat 7.1 to this year's Red Hat Enterprise 
Linux.  And asking our Windows customers to download your source and 
compile it is just something they don't have the time, inclination,
or training to do.  Even one ISP customer, who runs Linux on everything,
says he doesn't have time to keep up with all this since he has a LOT 
of other things he has to do, every day.

There's another problem.  We wrote HOWTO files on installing various
Red Hat versions to support our software, and we told them they
didn't need the Development RPMs. I doubt if any of our customers have
compilers on their servers, and the Microsoft customers may not even
have another computer in their organization that's running Linux.

These customers bought our spam filtering technology because of
what it does.  One of the things it doesn't do is Bayesian filtering.
I settled on Bogofilter as an open source "plug-in" that would work
with our software because I'd once heard Eric Raymond talk at MIT and 
because of the initial results that I'd gotten with Bogofilter.

But we won't be successful in getting our customers to use Bogofilter
unless we compile it here and give them a source+binary ISO to install.
But to do that, since some customers are running RH 7.1, I had to build
it on a 7.1 system and then bundle Sleepycat's libdb-3.1.so with it.  
Yeah, I know, not an optimal solution.  That's why I would like to have 
a bogofilter-static RPM that my customers could download and that they 
could install using scripts that I would provide.  

Matthias Andree's message of a couple days ago goes a long way to 
explaining why this may not be possible: 

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

Matthias' points also indicate that I might even expect problems with
my lowest-common-denominator distributions.  It might even explain some 
strange behavior at one customer site that has more CPUs than does
the system I compiled on.

And so we are left with some sites that are willing to use Bogofilter,
but only if it is pre-built for them, and all kinds of reasons why
it may not be possible to pre-build a binary distribution.  This is
not meant to be negative in any way regarding Bogofilter -- it just 
may not be possible.

But I think if you can find a solution, this is a good opportunity
to help spread the open source experience into organizations that
are still using mostly Windows servers.

Someone commented on the expensive nature of Red Hat Enterprise Linux.
That's why I was looking at CentOS.  See www.centos.org.  One more
platform, but apparently their rpm executable can't handle David's
bogofilter-static RPM.  Yet another dimension to the problem.

Regards, and thanks to everyone,

Al Donaldson