The Hermit Hacker writes:
> I don't agree ... unless we're gonna add this for libreadline
> (optional) and anything else that is "optional".
We already do this for everything else that's optional, except for
readline, which I consider wrong, but there's probably no support to be
gained for that. The fact that it is virtually impossible to determine
whether readline and/or history support is supported in psql until you
have installed and used it is a major source of user problems.
> IMHO, if the system has the functionality that extends the usefulness
> of the software, don't make the installer go off looking for how to
> make use of it ...
That's why I suggested assuming it by default and turn if *off* manually.
The reason why I'm so keen about this is this: configure scripts are not
only run by humans, but also by programs, and the only thing programs can
rely on is a non-zero exit status. config.status is one such program.
Others are source RPMs and other packaging mechanisms. Rebuilding a source
RPM is an enlightening experience: You get all kinds of garbage flying by
on your screen, and the end you only hope that something reasonable came
out. But if not even the build script can determine what it's going to
build, then you really lose.
The failure modes are plenty. You don't even have to be on a different
machine or fiddle with your installed packages. Maybe the sysadmin simply
reran /sbin/ldconfig after forgetting for a few months. Before you know it
you have shipped the package off to thousands of people who wonder why
feature X won't work.
The bottom line is, the packager/builder needs a way to specify what
exactly is going to be built.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
