<div><br><div class="gmail_quote"><div dir="auto">On Mon, Apr 16, 2018 at 7:02 PM ChenQi <<a href="mailto:Qi.Chen@windriver.com">Qi.Chen@windriver.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/16/2018 07:05 PM, Andreas Müller wrote:<br>
> Hi,<br>
><br>
> I am not happy plastering patches around for musl. This gets even<br>
> worse when I see patches like this [1]: Just wipe away security checks<br>
> unconditionally - the developers did introduce this check not just for<br>
> fun I guess...<br>
><br>
> I have seen this already elsewhere so: musl maintainers please take<br>
> care not to modify code for glibc!</blockquote><div dir="auto"><br></div><div dir="auto">The idea of musl is not to create a cocoon and live in it but on the contrary it’s about fixing the packages such that they work on any posix complaint libc regardless having said that there are packages which are coded for glibc and we</div><div dir="auto">Might have to keep trying to fix them upstream</div><div dir="auto"><br></div><div dir="auto">So in the spirit we are making changes such that</div><div dir="auto">They work across the board and then also push </div><div dir="auto">These patches to respective upstreams so far we</div><div dir="auto">Have done good job and upstreamed a whole bunch of patches this would not have been possible if we did the conditional approach </div><div dir="auto"><br></div><div dir="auto">We would not like to introduce regressions for sure and if you see regressions please report them ASAP and if you have fixes even better</div><div dir="auto"><br></div><div dir="auto">I am hoping that in the end applications will</div><div dir="auto">Become more portable and we will also see </div><div dir="auto">The cruft clearly that has gone into glibc over the years and be able to address it as you can see there is lot of cleanup happening in glibc already as a result</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
><br>
> [1] <a href="https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/systemd/systemd/0001-Use-getenv-when-secure-versions-are-not-available.patch" rel="noreferrer" target="_blank">https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/systemd/systemd/0001-Use-getenv-when-secure-versions-are-not-available.patch</a><br>
><br>
> Andreas<br>
<br>
Hi Anreas,<br>
<br>
I can see I rebased this patch. So I think I need to reply.<br>
<br>
I agree with you that musl related patches should not affect glibc.<br>
How about we using something like SRC_URI_append_libc-musl to organize <br>
the musl related patches?</blockquote><div dir="auto"><br></div><div dir="auto">No we should not unless the issue can’t be fixed in a compatible way</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Or do you have some other suggestion?</blockquote><div dir="auto"><br></div><div dir="auto">Fix in portable way and contribute the same to package upstream </div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Best Regards,<br>
Chen Qi<br>
-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote></div></div>