[OE-core] musl patches

[Khem Raj]

On Mon, Apr 16, 2018 at 7:02 PM ChenQi <Qi.Chen at windriver.com> wrote:

> On 04/16/2018 07:05 PM, Andreas Müller wrote:
> > Hi,
> >
> > I am not happy plastering patches around for musl. This gets even
> > worse when I see patches like this [1]: Just wipe away security checks
> > unconditionally - the developers did introduce this check not just for
> > fun I guess...
> >
> > I have seen this already elsewhere so: musl maintainers please take
> > care not to modify code for glibc!


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
Might have to keep trying to fix them upstream

So in the spirit we are making changes such that
They work across the board and then also push
These patches to respective upstreams so far we
Have done good job and upstreamed a whole bunch of patches this would not
have been possible if we did the conditional approach

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

I am hoping that in the end applications will
Become more portable and we will also see
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

>
> >
> > [1]
> https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/systemd/systemd/0001-Use-getenv-when-secure-versions-are-not-available.patch
> >
> > Andreas
>
> Hi Anreas,
>
> I can see I rebased this patch. So I think I need to reply.
>
> I agree with you that musl related patches should not affect glibc.
> How about we using something like SRC_URI_append_libc-musl to organize
> the musl related patches?


No we should not unless the issue can’t be fixed in a compatible way

>
> Or do you have some other suggestion?


Fix in portable way and contribute the same to package upstream


>
> Best Regards,
> Chen Qi
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180417/e74e185a/attachment-0002.html>