Re: 01/02: gnu: libressl: Update to 2.5.3.

[Ludovic Courtès]

Mark H Weaver <address@hidden> skribis:

> Leo Famulari <address@hidden> writes:
>
>> 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")))
>
> Ludo's approach looks good to me.

Thanks for checking.  Committed.

>> 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 :)
>
> It's not just about not providing substitutes.  At present, our libressl
> simply won't work properly on systems with older kernels, including
> hydra.gnu.org and our x86 build slaves.
>
> One issue is that there's a longstanding hope for us to switch to using
> libressl for most or all packages that currently use openssl.  We would
> be blocked from doing that if we accept that our libressl won't work on
> older kernels.

Yeah, I think we have to be consistent about what our kernel requirement
is.  With libc unconditionally providing syscall wrappers like this one,
it’s easy to let incompatibilities slip through.

Ludo’.