Re: [OE-core] [PATCH OE-Core 0/5] connman: Update for all PACKAGECONFIG options, clean up legacy

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2025-04-03 at 12:46 -0400, Scott Murray wrote:
> On Thu, 3 Apr 2025, Richard Purdie wrote:
> 
> > On Thu, 2025-04-03 at 07:42 +0100, Alex Kiernan wrote:
> > > On Wed, Apr 2, 2025 at 8:33 PM Richard Purdie
> > > <richard.purdie@linuxfoundation.org> wrote:
> > > > 
> > > > On Wed, 2025-04-02 at 16:02 +0000, Alex Kiernan via lists.openembedded.org wrote:
> > > > > connman has a legacy style, this patch set adds in all the PACKAGECONFIG
> > > > > options which the upstream pacakge supports, removes patches which are no
> > > > > longer required, explicitly supports operation alongside systemd-resolved and
> > > > > reworks the packaging so that PACKAGECONFIG and explicit package selection for
> > > > > every VPN is no longer required.
> > > > > 
> > > > > Everything up to the final patch should be backward compatible cleanup of the
> > > > > existing recipe, with only the final patch reworking the packaging.
> > > > > 
> > > > > Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
> > > > > ---
> > > > > Alex Kiernan (5):
> > > > >       connman: Merge .inc into .bb
> > > > >       connman: Delete patches for gold and MIPS binutils fix
> > > > >       connman: Move ppp from DEPENDS to PACKAGECONFIG
> > > > >       connman: Add all build options as PACKAGECONFIG
> > > > >       connman: Rework to avoid splitting into many single binary packages
> > > > > 
> > > > >  meta/recipes-connectivity/connman/connman.inc      | 221 ---------------------
> > > > >  ...vice-stop-systemd-resolved-when-we-use-co.patch |  26 ---
> > > > >  ...ange-visibility-to-default-for-debug-symb.patch |  31 ---
> > > > >  .../connman/connman/no-version-scripts.patch       |  47 -----
> > > > >  meta/recipes-connectivity/connman/connman_1.44.bb  | 154 +++++++++++++-
> > > > >  5 files changed, 147 insertions(+), 332 deletions(-)
> > > > 
> > > > This failed in testing on the first try. I've added:
> > > > 
> > > > diff --git a/meta/recipes-core/images/build-appliance-image_15.0.0.bb b/meta/recipes-core/images/build-appliance-image_15.0.0.bb
> > > > index 03f02d14ae8..c5ddea79005 100644
> > > > --- a/meta/recipes-core/images/build-appliance-image_15.0.0.bb
> > > > +++ b/meta/recipes-core/images/build-appliance-image_15.0.0.bb
> > > > @@ -6,7 +6,7 @@ LICENSE = "MIT"
> > > >  LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
> > > > 
> > > >  IMAGE_INSTALL = "packagegroup-core-boot packagegroup-core-ssh-openssh packagegroup-self-hosted \
> > > > -                 kernel-dev kernel-devsrc connman connman-plugin-ethernet dhcpcd \
> > > > +                 kernel-dev kernel-devsrc connman dhcpcd \
> > > >                   tzdata python3-pip perl-misc"
> > > > 
> > > >  IMAGE_FEATURES += "x11-base package-management splash"
> > > 
> > > Is keeping all those RPROVIDES (plus doubtless more at this point)
> > > actually useful? I can see it in the traditional distribution world,
> > > but for OE-Core it feels mostly redundant to me.
> > 
> > Short term, it will help fix people's builds and give some level of
> > runtime compatibility. Long term, it would be deadweight we carry. I'm
> > therefore torn.
> > 
> > I did note that meta-agl ran into a similar issue:
> > 
> > https://autobuilder.yoctoproject.org/valkyrie/#/builders/55/builds/1250
> > 
> > With the above tweak and the tweaked nftables, the rest of the build
> > was ok through.
> 
> If you're leaning towards taking it, we can adapt in AGL, though I can't
> guarantee there won't be a brief instance of AB breakage before I push
> a change.  Overall, I'm a bit ambivalent about removing the split out
> packages.  I understand the desire for simplifying it, but I also see
> some benefits to still mirroring what most other distributions do with
> networkmanager packaging since there still seems to be some interest in
> attempting to do binary packagefeeds...

To be honest, I'm torn, I could be persuaded either way. 

I copied more people to collect viewpoionts as well as make them aware
of the potential breakage.

Cheers,

Richard