Willy,
Am 14.06.19 um 15:01 schrieb Willy Tarreau:
> Hi again,
>
> On Wed, Jun 12, 2019 at 07:17:29PM +0200, Willy Tarreau wrote:
>>> 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.
>
> So does anyone have an opinion about the proposal above. Do not try
> to be gentle, "this is stupid" or "don't change anything at this point"
> are fine to me. I'd just want to be sure that whatever choice we make,
> it will have been given some though and will not just be the result of
> "oops we again forgot to change this".
These aliases still have the issue that the development headers are not
necessarily installed, even if the distro has the headers available. I'm
not sure whether there even is a need to change anything at all:
- The uneducated user will simply use whatever their distro maintainer
(or third party repository maintainer) selects for them. They don't
touch `make` at all.
- The distro maintainer can be expected to be smart enough to take a
look into the Makefile and enable all the options that are available on
the distro.
- The power user most likely wants to customize his build to include
exactly what they need (e.g. disable Lua).
None of these groups would really benefit from a `linux-recent` target!
Instead I suggest to:
1. Add a `linux` target that is equivalent to `linux2628` (thus being
equivalent to the linux-minimal from your suggestion above).
2. Remove all the other linux targets that target kernels from a
bazillion years ago. If anyone actually has a need to run these AND also
run a bleeding edge HAProxy they can be expected to be smart enough to
use TARGET=generic and select all the other options.
If we really want to make it easy for users then we should add an
autoconf script that automatically spits out a line with all the
supported options (and possibly `apt-get` commands to install the
remaining headers that are not supported).
Best regards
Tim Düsterhus
