From: Adrian Bunk <bunk@stusta.de>
To: Andre McCurdy <armccurdy@gmail.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: Should systemd be marked as incompatible with musl?
Date: Wed, 29 May 2019 10:31:01 +0300 [thread overview]
Message-ID: <20190529073101.GB23804@localhost> (raw)
In-Reply-To: <CAJ86T=X9grKeXkZMBL0zh6TeTRoyxg_TL3D=ADYvnH_L-6s3nw@mail.gmail.com>
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@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.
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.
> > 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.
>...
> 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.
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
next prev parent reply other threads:[~2019-05-29 7:31 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-23 10:33 Should systemd be marked as incompatible with musl? Adrian Bunk
2019-05-23 12:22 ` Burton, Ross
2019-05-24 1:45 ` ChenQi
2019-05-24 2:16 ` Khem Raj
2019-05-24 10:12 ` Adrian Bunk
2019-05-24 16:13 ` Khem Raj
2019-05-24 17:27 ` Adrian Bunk
2019-05-24 17:31 ` Khem Raj
2019-05-24 17:58 ` Adrian Bunk
2019-05-24 18:04 ` Khem Raj
2019-05-24 18:45 ` Adrian Bunk
2019-05-24 19:34 ` Andre McCurdy
2019-05-24 19:47 ` Khem Raj
2019-05-24 20:28 ` Adrian Bunk
2019-05-24 22:25 ` Andre McCurdy
2019-05-25 7:25 ` Adrian Bunk
2019-05-28 23:10 ` Andre McCurdy
2019-05-29 7:31 ` Adrian Bunk [this message]
2019-05-29 9:01 ` Khem Raj
2019-05-29 10:29 ` Adrian Bunk
2019-05-29 19:04 ` Andre McCurdy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190529073101.GB23804@localhost \
--to=bunk@stusta.de \
--cc=armccurdy@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.