Brett Glass <brett(_at_)lariat(_dot_)org> writes:
At 01:02 AM 4/9/99 -0500, Philip Guenther wrote:
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.
Huh? Apache doesn't just generalize about the broad category of the
system. To quote the src/Configure file from apache 1.3.6:
case "$PLAT" in
*mint)
OS="MiNT"
CFLAGS="-DMINT"
LIBS="$LIBS -lportlib -lsocket"
DEF_WANTHSREGEX=yes
;;
*MPE/iX*)
OS='MPE/iX'
CFLAGS="$CFLAGS -DMPE -D_POSIX_SOURCE -D_SOCKET_SOURCE"
LIBS="$LIBS -lsocket -lsvipc"
LDFLAGS="$LDFLAGS -Xlinker \"-WL,cap=ia,ba,ph,pm;nmstack=1024000\""
CAT="/bin/cat" # built-in cat is badly broken for stdin redirection
;;
*-apple-aux3*)
OS='A/UX 3.1.x'
CFLAGS="$CFLAGS -DAUX3 -D_POSIX_SOURCE"
LIBS="$LIBS -lposix -lbsd"
LDFLAGS="$LDFLAGS -s"
DEF_WANTHSREGEX=no
;;
...
That looks pretty specific to me.
Apache builds on just about everything because someone has stuck lines
in there for just about everything. If a significantly different new
version of an OS comes out, it'll make the wrong decisions. Several
versions of apache refused to use the regexp code that came with
Solaris 2.5 because previous versions of Solaris were broken. If they
had instead written a piece of code that tests the POSIX-compliance of
the regexp routines then that would not have happened. Completely new
platforms get the message
Sorry, but we cannot grok "$PLAT"
...
Ideally, read the file PORTING, do what it says, and send the
resulting patches to The Apache Group by filling out a report
form at http://www.apache.org/bug_report.html. If you don't
wish to do the port yourself, please submit this output rather
than the patches. Thank you.
Pressing on with the build process, but all bets are off.
Do not be surprised if it fails. If it works, and even
if it does not, please contact the above address.
and then it assumes some set of defaults and prays. That seems less
than helpful.
As for broad categories, they've blurred so much in recent years that
it really doesn't tell you anything useful. Let's say the initmake
script determined that the system was BSDish. How is that going to
change it's behavior? If something is harmless, it may be because it's
useless.
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,
Yeah, I've written those sorts of scripts too. You notice how they
keep growing, and how annoying they are when they guess wrong?
Looking at the open source software community, it seems to me that the
vast majority of packages have settled on a default directory layout
that can be altered at configure or compile time instead of trying to
match the platform. The only exceptions that I can think of are
sendmail and BIND. Sendmail has even gone to always putting the
sendmail.cf in /etc, ignoring what the vendor had choosen, as it kept
breaking support programs and made platform support more difficult.
/etc, /usr/local/etc, /var, and /stand. The procmail autoconf scripts
already look to see where sendmail is; why not other things?
That's done for two reasons:
1) sendmail has historically been placed in locations not in the
default PATH; and
2) sendmail might not be installed, in which case $SENDMAIL should be
"/usr/bin/smail" or something like that.
...
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,
Tripwire is an argument _for_ placing the ETCRC in /etc: the ETCRC
should be watched as closely as any other mail configuration file.
It's not like the procmail installation touches the file.
but it's easy to detect FreeBSD (and NetBSD and OpenBSD) and support
this organizational scheme.
It doesn't matter how easy doing this for one or three platforms is.
It matters how difficult doing this for 100 platforms is. I'm not
going to take procmail down that road.
Philip Guenther