All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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.