Hi,
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. Olivier
