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.


Reply via email to