Brett Glass <brett(_at_)lariat(_dot_)org> writes:
At 10:55 PM 4/8/99 -0500, Philip Guenther wrote:
Sorry, but I'm not "GNUish." ;-) It seems to me that whatever shell the user
is used to -- and knows -- ought to be the one that is used to interpret
the commands that he or she writes. I know that it is Richard Stallman's
desire to force bash and other GPLed software upon others, but I don't
personally think it's appropriate to do so. I always specify the shell
explicitly in Makefiles I distribute if it matters... but I do my best
to make sure it doesn't matter.
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 and yet
some other usable shell exists that is Bourne/ksh/POSIX compatible
(perhaps installed locally). The installer can override the default by
putting SHELL=/usr/local/bin/pdksh (or whatever) in the initial
Makefile or on the make command line and initmake will preserve that as
long as it isn't a csh or zsh variant.
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.
No, I didn't disable fcntl() locking -- I only changed that one path.
Are there other things that should be changed? If so, perhaps they
should be in the Makefile as well! Many people, I expect, will build
directly from your distribution rather than going to the FreeBSD
ports. As with Apache, it may make sense to handle OS issues in the
Makefile....
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.
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?
Of the five patches to procmail in the ports tree, two fix
bugs that were resolved in 3.12, two tweak the makefiles to match the
ports build system, 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 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.
Philip Guenther