Re: [meta-networking][PATCH] networkmanager: Update to 1.18.0

From: Adrian Bunk <bunk@stusta.de>
To: Khem Raj <raj.khem@gmail.com>
Cc: Andrei Gherzan <andrei@gherzan.ro>,
	openembeded-devel <openembedded-devel@lists.openembedded.org>
Subject: Re: [meta-networking][PATCH] networkmanager: Update to 1.18.0
Date: Tue, 28 May 2019 21:06:55 +0300	[thread overview]
Message-ID: <20190528180655.GA14708@localhost> (raw)
In-Reply-To: <CAMKF1srx8acL-pQu6HWt3KutcvTNu=X-Fweos2XZ6vO-mLyK7Q@mail.gmail.com>

On Tue, May 28, 2019 at 09:14:17AM -0700, Khem Raj wrote:
> On Tue, May 28, 2019 at 8:37 AM Andrei Gherzan <andrei@gherzan.ro> wrote:
> 
> > On 28/05/2019 16.13, Khem Raj wrote:
> > > Hi Andrei
> > >
> > > The musl patches need to be forward ported as well. They dont apply
> > > cleanly anymore on top of this update.
> >
> > Seems like. So all the contributions now need to go through local musl
> > and glibc testing? This sounds a little bit of an overhead and might
> > discourage people in contributing because usually everyone is working on
> > one libc variant. Just raising it as a concern. As per this specific
> > case, I'm going to fix it and push a V2.
> 
> 
> I understand that and in some cases it’s even narrower where one might just
> be working on one distribution alone for single architecture for that case
> failure on architectures they don’t care is
> also a nuisance
> 
> It’s wide and far testing we can achieve is good for end user same goes for
> multiple architectures if someone tests a given architecture and reports
> build  failures then it’s good to acknowledge that imo
> 
> It’s not a blocker I expect someone interested in a given regression of
> this kind to chime and help if possible so don’t see it as an impediment

Is anyone actually using networkmanager with musl?

There are no obvious usecases where it makes sense, and OE seems to be
adding security vulnerabilities in the musl build that are not in the 
glibc build (e.g. -Dsecure_getenv=getenv) so users should better not
use it in any case.

> If we remain cognizant of the fact that upstream might have wider usecases
> we will generally be better off cumulatively

Upstream ships a copy of systemd code for use as library.

This already implies that trying to support it for musl will be a 
long-term pain of not upstreamable patches for OE contributors.

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