On Wed, May 29, 2019 at 9:31 AM Adrian Bunk <b...@stusta.de> wrote: > > On Tue, May 28, 2019 at 04:10:45PM -0700, Andre McCurdy wrote: > > On Sat, May 25, 2019 at 12:25 AM Adrian Bunk <b...@stusta.de> wrote: > >... > > > Supporting musl is a real pain across the board, > > > with new issues all the time. > > > > There are always new issues and bugs to be solved in OE as a > > consequence of trying to keep all packages up to date. Whether the > > issues arising from musl are a real pain or a fun new set of problems > > to solve is mostly a matter of perspective. > > Usually someone submits a change, and later gets notified that the > change was dropped from master-next due to a musl issue. > > That's not fun.
I have re-iterated many times that if your patch regresses musl and you dont want to fix it when I provide feedback on the patch, say it there. master-next is merely an integration branch it does not mean that if a patch shows up on master-next then its any good or bad for that matter its for CI purpose only. master-next queue gets re-aligned all the time. My point to drop the patch is that submitter would be interested in fixing it which most of the times submitters are kind enough but I will respect reluctance to fix musl of for that matter larger OE interests that a developer might not care. Many developers have chipped in to fix regressions in past and I am hopeful they will chime in future too. OE is not a distro, its an infrastructure to build custom distros and thats its USP, if we were to stick with one distro then there are plenty out there which are far well supported. > > And all these compile errors with musl due to header order are a real WTF, > every other library (not limited to C libraries) is now doing headers > properly so that any order works. No fun in supporting a broken design. > I think these are concerns you must raise in musl community, OE is downstream where we can experiment but not fix these problems, thy should be fixed in repsective upstreams as much as possible upsttream might have answers or might benefit from this feedback > > > For really tiny systems you need both a tiny C library and a tiny init> > > > system, so not properly supporting the combination of both forces users > > > to use alternative options instead of OE. > > > > > > Which minimizes the benefits gained by the pains of supporting musl. > > > > A modern tiny init system would be nice to have, but it's not > > essential or fair to say that musl is useless without one. Many > > projects, especially tiny ones, manage fine with init scripts and > > custom process management. > > I was not asking for "modern". > > If init scripts are not default and CI tested with musl, > then init scripts will soon become a broken part of OE. Infact, there are CI system not exposed to community where its testing sysvinit with musl > > >... > > A few pragmatic patches applied by OE would go a long way to bridging > > the conflicting goals of the two upstream projects. It's basically the > > approach we've taken already - the question is just one of improving > > the patches we already have (and maybe patching musl to add missing > > functionality instead of only trying to patch systemd to not depend on > > it). > > I already tried patching musl in OE. > The change got reverted. > Its costly to change fundamental APIs in libc which are not accepted upstream, especially in libc which will go into SDKs and will become default API set solely provided by OE thats a huge cost in time. I suggested you to submit the patch upstream musl, I still encourage you to do so. > There are people who think that OE-specific patches to musl are not > acceptable, and that it is better to force everyone in OE to patch > individual packages all the time instead of adding a not upstreamable > patch to musl. > I think you understanding is a bit different here, more than one package using a specific non-standard API does not legitimize it to become part of C library, Ask glibc developer community they would tell you how much libraries and functions they want to drop but can not. > cu > Adrian > > -- > > "Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. > Pearl S. Buck - Dragon Seed > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core