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

[Andre McCurdy]

On Wed, May 29, 2019 at 12: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.

Maybe that happens sometimes but I'm not sure that's the "usual" case.
Patches to OE get dropped or ignored for many reasons. If your patch
gets as far as master-next and then gets dropped with some feedback
it's already done better than many others :-) If you're going to
contribute to OE you need to listen to the feedback... and be a little
persistent!

> 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.

The musl header ordering issues (the potential for duplication of
definitions between low level kernel headers and libc headers) is
specific to C libraries. It's actually a perfect example of a problem
created by a hard line stance from upstream musl which could be
completely solved by a small pragmatic patch applied by OE.

> > > 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.

By that definition (ie anything which is not CI tested is broken) then
most of OE is broken. CI testing covers a very narrow set of
configurations and if you configure for a real world project you're
likely to stray away from them. A few releases back, openssh didn't
work for Thumb2 targets because of a conflict between binutils and
openssl but wasn't caught by CI testing because (at the time) CI
testing was ARMv5 only. In OE 2.7, sqlite3 is broken for big-endian
ARM targets (which aren't part of the CI testing). There are many
other examples. If you plan to use OE in a real product you'd better
plan to do your own CI testing and bug fixing. For many (most?) users
that's perfectly acceptable - it's far better to have functionality in
OE which is basically sound but may need some tweaks than to strip out
everything which hasn't been CI tested.

> >...
> > 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.
>
> 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.

Yes, I saw that. The rules on what is and what is not acceptable in OE
are not particularly well defined (and then not consistently applied).
It's just the way it is...