Le mer. 12 juin 2019 à 19:19, Willy Tarreau <w...@1wt.eu> a écrit :

> Hi guys,
> On Wed, Jun 12, 2019 at 04:27:42PM +0200, Lukas Tribus wrote:
> (...)
> > I think it's a bad idea.
> >
> > Basically what Tim says (I was interrupted several times while writing
> > this email).
> OK, and this morning William told me he thought the same for the same
> reasons, so definitely I'm the one wrong here, which justifies that I
> asked. And I totally agree with your arguments.
> (...)
> > Those will be the interactions, with a lot of round-trips back and
> > forth. At least the user understands that USE_LUA=1 means that LUA
> > will be included. With TARGET=ubuntu18 the user may not even know what
> > LUA is, let alone that it's a dependency.
> I was actually thinking about enabling what I expect to be installed
> by default, i.e. zlib & openssl mainly. But at first I didn't want to
> address libraries as much as the default OS which involves a minimal
> kernel version and a libc. In the past we've had to guess quite a few
> times some settings, which were nicely addressed by the split on kernel
> 2.6.28, but it seems cleaner to support a kernel+libc combination, which
> is what made me think about distros, hence their respective libs.
> > So do we brake the build by
> > default and just document in INSTALL that in Ubuntu 18.04 the LUA
> > dependency must be fulfilled by installing the source package, which
> > can be either liblua5.1-0-dev, liblua5.2-dev or liblua5.3-dev?
> I agree.
> > INSTALL already contains suggestions about what USE_ flags to include,
> > as a matter of fact all 5 external libraries mentioned above are
> > suggested:
> >
> >
> http://git.haproxy.org/?p=haproxy.git;a=blob;f=INSTALL;h=9df17caf68c4f00cdaaaec2ec929f0af66e1d297;hb=HEAD#l35
> >
> >
> > To be honest, I don't think this is very common in OSS projects; most
> > of them use configure scripts that just include the library if the
> > headers are detected, or not link against it at all if it isn't there.
> > But we would brake the build here, which is different.
> 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).
> 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.
> > > just like we already have for solaris/openbsd/freebsd for example
> >
> > None of these include external libraries though, like OpenSSL, LUA,
> > zlib, PCRE1/2. Only kernel features and "very core" libraries are
> > included with the solaris/BSD targets (just like linux2628). So the
> > build may brake because a basic and crucial threading lib is missing,
> > but not because LUA is not there. That's very different kind of build
> > failure.
> Agreed, probably that I was a bit too enthousiast by this idea and
> conflated several things. We should probably get back to platform and
> features separately. openssl, lua, zlib, pcre are in fact features if
> they are not present by default. I was happy to place some of them by
> default but if they are not necessarily present, let's not force :-)
> thanks guys for fueling the discussion.
> Willy

Sorry if I'm totally "out" on this point, but I was wondering why HAProxy
did not provide a simple "configure" script : all available options would
be listed (I know it's in the doc, but hey, how many people do actually
read it ? :p). and script will check if options chosen can be compiled (if
pcre2 is available, if openssl-devel is available, and so on ...).
You may then pick a default config, for example SSL always compiled in, LUA
not, ... if no other option are provided.


Reply via email to