At 01:02 AM 4/9/99 -0500, Philip Guenther wrote:
The only reason doesn't just set SHELL=/bin/sh at the top of the
Makefile is that there are systems which have a broken /bin/sh
Really? This would be a very critical thing to have broken. If
there's any program I'd expect to be standard and operational
on a UNIX system, it'd be sh. At the very least, I'd expect that
it'd be symlinked to something that works.
Building in knowledge of specific platforms is a bad idea if it is at
all possible to avoid it: it makes the package _less_ portable and more
difficult to maintain. While more difficuly initially, writing a test
for the feature or bug is generally a more robust configuration method,
as it automatically handles new OS versions and ports. Consider:
apache has more lines of shell script devoted to handling OSes case by
case than procmail's automake and autoconf scripts have all together.
Tests can work as well. But there's no harm in generalizing about certain
broad categories of platforms -- e.g. BSD-like UNIXes vs. System V-like
UNIXes. This is what Apache does, and it really does build on just
about anything.
As for things that can't really be tested for, such as filesystem
layout, trying to guess them correctly would be hit and miss to begin
with (not every FreeBSD system puts procmail in /usr/local/bin), and
even more difficult to maintain. Why should the whims of each system
vendor be encoded into the procmail souce?
They don't belong in the program itself, but it's perfectly permissible
to put them in Makefiles and/or other preconfiguration programs. And
it is possible to do SOME testing of filesystem layout.... I've done it
in my own installation programs. You can tell a lot by checking what's
in /sbin, /usr/sbin, /bin, /usr/bin, /usr/local, /usr/local/bin,
/etc, /usr/local/etc, /var, and /stand. The procmail autoconf scripts
already look to see where sendmail is; why not other things?
Of the five patches to procmail in the ports tree, two fix
bugs that were resolved in 3.12,
Two down....
two tweak the makefiles to match the
ports build system,
Another two down....
and the last disables fcntl locking and changes
TRUSTED_IDS, ETCRC, and ETCRCS. The TRUSTED_IDS change -- adding
majordomo to the list -- seems pointless to me (since when did
majordomo call procmail directly?), while the ETCRC and ETCRCS changes
are to match a choice made by the FreeBSD people which I don't think
should be forced on the rest of the world.
The ETCRC and ETCRCS changes are a good idea, I think; /etc tends to
be overused for programs which aren't part of the OS distribution (Sort
of the way \WINDOWS and \WINDOWS\SYSTEM are abused in Microbloat Windoze).
They also prevent false alarms if you're running something like Tripwire
to watch /etc closely. I agree that they should be a matter of choice,
but it's easy to detect FreeBSD (and NetBSD and OpenBSD) and support
this organizational scheme.
The TRUSTED_IDS change may be useful if Majordomo is attempting to
deliver mail locally via the local mail delivery agent. I don't run
Majordomo myself, but I'd be curious, so I'm copying the port
maintainer on this message in the hope that he'll explain this.
The fcntl() change even seems dubious: the comment in the CVS log would
seem to indicate that this was not because fnctl() locking is broken,
but as a speed increase. If so, this may lead to interoperabilty
problems if flock() doesn't interact with fcntl() locking on another
host when both are accessing the same file through NFS. If it does
interact, then either the change is superfluous or FreeBSD's fcntl() is
broken or inefficient.
I'm not an expert on the mysteries of different file locking schemes, but
I *do* see that the tests in your automatic configuration scripts currently
would lead to the use of fcntl() locking under FreeBSD.
Here's the autoconf.h that was generated during my compile:
/* This file was automagically generated by autoconf */
/* 64 moves in 64 steps of size 16384 when reallocing */
#define INEFFICIENTrealloc
#define GOT_bin_test
#define MAX_argc 3735
/* Your system's strstr() is 1.19 times SLOWER than my C-routine */
#define SLOWstrstr /* using my substitute instead */
#define UDP_protocolno 17
#define BIFF_serviceport "512"
#define IP_localhost {127,0,0,1,}
#define MAILSPOOLDIR "/var/mail/"
#define SENDMAIL "/usr/sbin/sendmail"
#define defPATH "PATH=$HOME/bin:/bin:/usr/bin:/usr/local/bin"
#define PM_VERSION "3.13.1"
/*locktype: 4, countlocks: 0, timeout 0, watchdog 8, /tmp/_locktest*/
/*locktype: 4, countlocks: 0, timeout 0, watchdog 8, ./_locktest*/
/*locktype: 6, countlocks: 80, timeout 0, watchdog 14, /tmp/_locktest*/
/*locktype: 5, countlocks: 80, timeout 1, watchdog 14, /tmp/_locktest*/
/* Hotwire LOCKINGTEST=100 */
/* Procmail will lock via: dotlocking, fcntl() */
/* autoconf completed */
Again, it'd be useful if the port maintainer could explain the rationale
for doing it differently, especially if there are potential problems with
NFS. Why does the port disable fcntl() locking?
--Brett Glass