> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bob
> Proulx
> Sent: Sunday, September 22, 2002 11:44 AM
> To: Spamassassin List
> Subject: Re: [SAtalk] -P warning considered harmful
>
>
> Gary Funck <[EMAIL PROTECTED]> [2002-09-21 13:59:38 -0700]:
> > Our mail server computer is offline at the moment, so we substituted
> > a spare, which generally has the same OS and software, but differs
> > in a few regards. It
> > [...]
> > The -P flag used to be in the recipe, but I removed it after
> > upgrading to v. 2.41 because I saw warning messages in procmail log
> > file, where the new version of SA noted that the -P flag is no
> > longer necessary.
>
> That was a good thing, that you saw the message and updated. Years
> into the future it is desired to forget that the -P option existed.
> It was a mistaken step in the development path of SA. The developers
> are moving foreward. Note that I am not an SA developer and I am
> speaking my own mind here.
>
> But by what method can one transition from a previous version to a
> newer version where incompatibilities exist?
Generally, by being upward compatible. In this case, SA is upward compatible
(in that -P is no longer required), however, the warning is noisy, and I think,
unnecessary. There are plenty of Unix programs out there that have an explicit,
yet optional, switch that tells the program to act like a pipe.
> It is very difficult but
> the path chosen by the SA developers is as good as anyone has ever
> been able to do. They created a transition version where the -P
> option is only a warning.
Frankly, if this is really an important issue, I'd prefer it if they made the
use of -P an error. Will certainly get the attention of the admins(!). But,
what I really think is that the -P warning just shouldn't be there.
>
> > Suggestion: remove the -P warning. The presence of -P doesn't hurt
> anything,
> > and the lack of backward compatibility can cause some surprising behavior.
>
> You are not experiencing a _backward_ compatibility problem but a
> _forward_ compatibility problem. You are moving from a newer version
> to an older version and that is creating your problem.
>
Whatever. Poor choice of words. Let's just view the problem as a situation
where we have a mixed environment with some machines running the older rev. and
some running the newer rev. However, we're invoking SA from each user's
.procmailrc (for now), and their .procmailrc's are located on NFS mounted home
directories, and may be invoked by different mail delivery systems on different
machines. The mail delivery systems on the different machines can't be updated
at once, and generally won't be, because it makes sense to do some testing on
one machine first. In this setting, it is really helpful for SA to be upward
compatible, and to not act in a way that encourages users and admins to
implement an non upward compatible change in their invocation of SA. Yes, the
.procmailrc recipe could check the SA version, but that is overly complex.
> You have two hosts one of which you are using as an alternate for the
> other.
We are. But, it wasn't planned that way. We had a limited time to make the
switch, because of a hardware failure. That is all a bit immaterial, because
there are many situations in which multiple machines are involved and it
doesn't make sense to upgrade them all instantaneously.
[...]
> Therefore there is, of course, a counter suggestion as well. You
> should upgrade your secondary host to the newer version.
No doubt. We just preferred to get the backup on the air as quickly as possible
and deal with upgrade issues incrementally.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
