On Thu, Apr 13, 2017 at 02:59:21PM -0400, Leo Famulari wrote:
> 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 :)

After reading more, I realized that my knowledge on this topic was even
weaker than I thought. So please disregard what I wrote here.