procmail
[Top] [All Lists]

Re: Global mail filtering turned off after latest version installed

1999-04-08 21:09:50
Brett Glass <brett(_at_)lariat(_dot_)org> writes:
I didn't know that that there WAS a predefined constant called ETCRC,
because when I first installed I installed a precompiled binary from
the FreeBSD ports collection. But the ports for the 2.2.8 version of the
OS are not being maintained, so to upgrade procmail I had to do my
own compile.

I went ahead and changed ETCRC (in config.h) and BASEDIR (in the
Makefile) and did a compile from a fresh copy of the tarball.
It compiled OK, except for an odd message which claimed that the
standard Berkeley make was "really perverted." (Why, I wonder?)

It means that Berkeley make inherits the value of the SHELL variable
from the environment, instead of setting it to the Bourne shell and
only letting the makefile or command line override it.  Why is this
'perverted'?  To quote the GNU make info pages:

   Unlike most variables, the variable `SHELL' is never set from the
   environment.  This is because the `SHELL' environment variable is used
   to specify your personal choice of shell program for interactive use.
   It would be very bad for personal choices like this to affect the
   functioning of makefiles.  *Note Variables from the Environment:


...
It might be a good idea to detect a BSD-based system and set BASEDIR and ETCRC
to /usr/local/whatever automatically. Maybe this is something worth adding to
the Makefile. I don't know if /etc/procmailrcs should also follow, but it seems
reasonable for it to do so.

If you previously were using a package from the ports collection and
you decide to move to a version not yet included therein, then you
should examine and possibly apply each patch in the ports tree to the
new version.  I've poked around the ports tree some just now and
patches are included not only to set a given directory arrangment but
also to deal with random other configuration issues and make
conventions.  Did you remember to disable fcntl() locking when you
upgraded to 3.13.1?  That's in the same patch as the change to ETCRC
and ETCRCS.

My point is that there's no sure fire way for procmail to deduce the
conventions that already exist on a system.  Why spend the effort to
guess and possibly get it wrong when the installer still has to
manually configure other items?


Philip Guenther