[oe] [meta-networking][RFC PATCH 0/1] Failed to compile networkmanager with musl

[Khem Raj]

On Wed, Aug 28, 2019 at 12:56 PM Adrian Bunk <bunk at stusta.de> wrote:
>
> On Wed, Aug 28, 2019 at 11:53:27AM -0700, Khem Raj wrote:
> > On Wed, Aug 28, 2019 at 11:06 AM Adrian Bunk <bunk at stusta.de> wrote:
> > >
> > > What about marking networkmanager as incompatible with musl instead of
> > > maintaining an ever-growing mess?
> > >
> >
> > if the fix is specifically done for musl alone then I would agree, but
> > in many cases, the fixes
> > have been cleaning up assumptions in kernel UAPI headers on glibc
> > provided headers
> > which is a good thing, and it does take some time for kernel header
> > changes to flow upstream
> > but eventually, they do. e.g. see [1]
>
> This is not a cleanup, this is a workaround for a misfeature of musl.
>
> The kernel userspace headers are the userspace ABI of the kernel for
> usage by all C libraries provided in one place, they are not tied to
> any specific C library.
>
> musl upstream does not even try to use the kernel userspace headers.
>
> The kernel userspace headers used to be a mess, but after more than 10
> years of cleanup there is no excuse for musl to insist on providing own
> definitions of what is already provided by the kernel headers.
>

I was citing an example, you might have good feedback maybe bring it up
upstream with musl or

> > > Networkmanager uses parts of systemd as a library and also has own
> > > glibc-only usages.
> > >
> > > Both systemd and networkmanager are fundamentally Linux-only,
> > > and for systemd it is known that upstream has made the design
> > > decision to not compromise their software for rare usecases
> > > with C libraries other than glibc.
> > >
> > > AFAIK OE is the only distribution trying to build either of these
> > > with musl, other musl-using distributions are using less heavyweight
> > > solutions.
> >
> > We should enable as much as possible we can and not go overboard in
> > supporting everything
> > except for core packages where it might be ok to put a bit of effort
> > and upstream the changes
> > network manager is quite useful in base images eg. xfce images etc
> >...
>
> When you are using networkmanager and xfce in your image,
> what is the point of using musl instead of glibc?
>
> Networkmanager alone has twice the size of glibc.
>

Size is just one of many reasons to use musl not the only one.

> There is a benefit of a small C library when your flash space is
> single-digit megabytes, but maintaining plenty of not upstreamable
> OE-only patches for using networkmanager on musl without a sane
> usecase is a waste of effort.

I have said it before as well, I will say it again if we can improve an upstream
packages portability that itself is a good thing, but we should not go overboard
if its too much of work. there are container distros using musl so we
have a wide
list of packages which work well with musl, and this list is always
increasing, so I
would refrain from pushing musl to a narrow usecase