Ted, I simply do not feel well enough just now to be nice. I reiterate my prior
observation about vaguely stinky and spludgy material such as emanates from the
South end of North facing fertile male bovines.
I have enough headaches with pure distro modules. I really REALLY *R*E*A*L*L*Y*
do not want to go through the nonsense again with off distro modules. I ran SA
off distro for a few years. I got tired of it. Too much stuff was starting to break.
Sorry if I am abusive - no - I'm not sorry. I feel like warmed over poo with
this blasted headcold. I DO NOT NEED THIS SORT OF AGGRAVATION JUST NOW PEEING ON
ME FROM MY LOGS.
{`,'}
On 2014-11-30 11:07, Ted Mittelstaedt wrote:
Now now, be nice!
This issue affects ANY piece of OSS software that has multiple dependencies.
SpamAssassin has HUNDREDS of dependencies on different Perl modules.
Using your nasty logic if the author of Perl::Date or whatever
decided to make a change that broke SA than it's our tough luck, eh?
The authors of any OSS project - like SA, like any of the modules that SA
depends on - that depends on OTHER OSS
projects need to navigate this dependency hell with same guiding
principle that is used for Sendmail and other OSS projects:
Be liberal in what you accept, conservative in what you send.
Meaning this - you write a package like SA, or a package like Perl::Date, that
has published interfaces and API's, you need to do your best to maintain
consistency, and you need to be accepting
of changes that others make to the best of your ability.
If the SA authors want to add bells and whistles to a functioning design that
require certain newer versions of dependent programs that's fine - but they need
to install logic in those bells and whistles that either makes them backwards
compatible with older dependent programs or turns those bells and whistles off.
If it turns out that an older released SA has a design flaw that makes that
impossible to do then patches need to be released for those older
versions.
There's no need to take a scorched Earth My way or the highway approach.
Ted
On 11/30/2014 10:50 AM, Dave Pooser wrote:
On 11/30/14 12:34 PM, "Paul R. Ganci"<ga...@nurdog.com> wrote:
So just so I understand something is it expected that those of us with
RHEL 5.11 and RHEL 6.6 servers are expected to upgrade our perl versions
just for spamassassin's sa-update? The whole idea of running servers
with those versions of server software is for stability.
Yep. And the whole point of running SpamAssassin with sa-update is for
flexibility and agility. The two goals are necessarily in conflict. So...
Looks like you have a few options:
1) Don't run SA on RHEL
2) Run SA on RHEL but turn off sa-update and sacrifice automated reaction
to new spam in the interest of keeping your system static
3) Run SA on RHEL but upgrade perl and SpamAssassin using
third-party-packages or update from source
4) Run SA on RHEL with system perl and system SpamAssassin, run sa-update
with output redirected to /dev/null, and write your own monitoring script
to tell you if sa-update broke spamd
5) Run SA in some kind of container or VM so you can optimize for
spamassassin without tainting the purity of your RHEL install
