On 6/14/2019 7:01 AM, Willy Tarreau wrote:
OK. When discussing this with William, we figured it could be interesting
instead to have some aliases which are maybe more symbolic, such as :
- linux-complete : full set of supported features, will simply fail
if you don't have all libs installed, useful primarily for devs ;
- linux-recent : common set of features present by default on latest
release of LTS distros at the time of releasing. I.e. could be the
default if you have a reasonably up-to-date system ;
- linux-ancient : common set of features present by default on oldest
supported LTS distros at the time of releasing. Should be a safe
fallback for everyone who doesn't want to care more ;
- linux-minimal : basically just oldest supported LTS kernel + equivalent
libc, would serve as a starting point to manually add USE_*..
In fact I'm still a bit concerned by the fact that we continue to
advertise 2.6.28 as the split point while no older kernels are still
supported, and that some of the features placed there very likely still
don't work well in embedded environments (openwrt for example).
What I've noticed is that for the most part, you can classify source
code downloaders in one of two camps: Either the complete novice, or
the experienced user. The complete novice wants steps that are very
simple, and the experienced user wants the build to be customizable with
myriad knobs and switches, and wants them all documented. I find that
membership in an "intermediate" camp is very small ... people tend to
either remain novices or gravitate towards expert.
Dividing the README into two parts, one for the novice and one for the
expert, would be reasonable to me.
The haproxy build is one of the more complex that I've encountered.
I've written a little shell script to handle building and installing it,
because I'll never remember all the make options I need without checking
the docs:
---------------------
root@smeagol:/usr/local/src# cat new-haproxy
#!/bin/sh
if [ -e "$1" ]; then
if [ -d "$1" ]; then
cd $1
make clean &&
make TARGET=linux2628 USE_PCRE_JIT=1 USE_OPENSSL=1 USE_ZLIB=1
USE_SYSTEMD=1 CPU=native
RETVAL="$?"
if [ "$RETVAL" = 0 ]; then
make install
else
echo Build failed\! skipping install\!
fi
else
echo location \($1\) is not a directory.
fi
else
echo location \($1\) does not exist.
fi
---------------------
It would be really nice if a novice could simply type "make install" and
have it build with "sane" options for whatever OS they're on. Maybe
having one static command (or set of commands) for almost every user
isn't achievable without additional software that you don't want to use,
such as autoconf.
That said, some simplification would be welcome. Aliases so that
"TARGET=linux" produces a generally useful build on most current Linux
distros would be AWESOME. The build should, as much as possible, check
that all options requested are possible, and fail fast if they're not,
with useful error messages.
General statement, not directed specifically at haproxy: I find it
frustrating to have a build get started, run for several minutes, and
then suddenly fail with a compiler message that may or may not be easily
translatable into "you don't have the XXX development library
installed." I can usually figure out what those errors mean, but the
novice user probably won't have any clue.
A new "linux" target should probably internally choose the most common
numbered variant. At the moment, that's the latest (2628), but at some
point in the future it might not be the latest. It does seem reasonable
to have the "linux" alias *not* enable any other options, and have other
aliases that enable things like ZLIB, SSL, PCRE, etc.
I'd like very much to get rid of this laughing "2.6.28" now but if we
only use "linux" nobody will update it and we'll be back to the same
situation in one or two versions. With the split above we can have
fast moving targets ("complete", updated during dev; "recent", updated
with new distro announces) and slow moving ones ("ancient", "minimal")
and that might be a sweet spot.
I've wondered about that, actually. Occasionally I wonder whether 3.x
or 4.x kernels (and now 5.x) might offer something new that could
improve haproxy. Because the target name hasn't changed in such a long
time, I have to assume that there hasn't been anything earth-shattering,
and that the options for 2.6.28 really do offer the best possible
performance on recent kernels.
I personally have no use for older Linux targets, but I feel pretty sure
that there are still plenty of systems running on ancient kernels, with
admins that want to build haproxy.
Thanks,
Shawn
