On Mon, Apr 16, 2018 at 7:02 PM ChenQi <qi.c...@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@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core >
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
