From: Khem Raj <raj.khem@gmail.com>
To: Adrian Bunk <bunk@stusta.de>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] musl: Add TEMP_FAILURE_RETRY from glibc
Date: Mon, 20 May 2019 14:24:47 -0700 [thread overview]
Message-ID: <b3084e96-3476-14ef-8fca-5d1fb30583e4@gmail.com> (raw)
In-Reply-To: <20190520211635.GA22230@localhost>
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.
>
prev parent reply other threads:[~2019-05-20 21:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-16 7:48 [PATCH] musl: Add TEMP_FAILURE_RETRY from glibc Adrian Bunk
2019-05-20 20:19 ` Khem Raj
2019-05-20 21:16 ` Adrian Bunk
2019-05-20 21:24 ` Khem Raj [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b3084e96-3476-14ef-8fca-5d1fb30583e4@gmail.com \
--to=raj.khem@gmail.com \
--cc=bunk@stusta.de \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.