[OE-core] [PATCH] musl: Add TEMP_FAILURE_RETRY from glibc

Khem Raj raj.khem at gmail.com
Mon May 20 21:24:47 UTC 2019



On 5/20/19 2:16 PM, Adrian Bunk wrote:
> On Mon, May 20, 2019 at 01:19:38PM -0700, Khem Raj wrote:
>>
>>
>> On 5/16/19 12:48 AM, Adrian Bunk wrote:
>>> Patch it into musl instead of patching all users
>>> (currently elfutils and next ofono).
>>
>> this violates musl philosophy, and I would like to stay as close as we can,
>> so I would suggest that you propose this patch to upstream musl first and
>> get an opinion, if it gets accepted, we can change OE
> 
> "musl philosophy" is that musl does include the GNU extensions Rich Felker
> likes, and does not include the GNU extensions Rich Felker dislikes.[1]
> 
> TEMP_FAILURE_RETRY is in the latter category.
> 

I would encourage you to start a discussion. Usually a good reason to 
accept or reject comes out of discussions.

> For TEMP_FAILURE_RETRY it's either patching musl once or patching random
> packages all the time, and the patch is not invasive.
> 

No other musl distro is patching musl especially for this case, we can 
live with that since packages will be patched. Eventually applications 
will wean away from using it.

>> Richard,
>>
>> Please revert this patch, I know its now in master, but we should wait until
>> upstream agrees to apply this, we are trying to extend C library which would
>> fall on us eventually forever if upstream does not accept it.
> 
> What is actually the strategy for handling musl changes that will have
> to be shipped in OE forever?
> 
> Especially systemd/musl is a combination that will bring an ever-growing
> amount of changes that cannot be upstreamed on either side.
> 
> And some of the OE patches to systemd make things compile but are of the
> "I wonder if I can get a CVE for that" kind.
> 
> The alternative would be to mark systemd as incompatible with musl,
> which might be the sustainable thing to do.
> 
> cu
> Adrian
> 
> [1] There seem to be sound technical reasons behind what he likes,
>      but this doesn't help when a distribution wants to get existing
>      software building with musl.
> 


More information about the Openembedded-core mailing list