[OE-core] Should systemd be marked as incompatible with musl?

[Khem Raj]

On Wed, May 29, 2019 at 9:31 AM Adrian Bunk <bunk at 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 <bunk at 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
>