On Thu, Apr 13, 2017 at 05:08:29PM +0200, Ludovic Courtès wrote:
> A simple approach is to force LibreSSL to always use its non-getentropy
> code, and lift this restriction once we clearly require newer kernels¹.
> The attached patch does that.
> 
> Thoughts?

> +     ;; Do as if 'getentropy' was missing since older Linux kernels lack it
> +     ;; and libc would return ENOSYS, which is not properly handled.
> +     '(#:configure-flags '("ac_cv_func_getentropy=no")))

If we are committed to building glibc with the 2.6 kernel headers, and
to providing substitutes for libressl and it's dependent packages, then
I think this patch is a good option.

But, it's a bit of a shame to leave this ~2.5 year old feature behind,
especially when the 2.6 Linux series is not even part of the Linux
long-term-support project. [0] These kernels *will* live for a long time
through support from RHEL; their most recent kernel on RHEL7 is 3.10.

However, I don't fully understand the impact of building glibc with a
newer set of headers, so my objection is a weak one :)

Personally, I don't think it's paramount to offer substitutes for the
packages in question. But I know this is an unpopular position, in
general :)

[0]
https://ltsi.linuxfoundation.org/
https://www.kernel.org/