Re: [OE-Core][PATCH v2] packagegroup-base: Add option to set zeroconf provider

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

On Sat, 2025-02-15 at 16:55 +0000, Alex Kiernan via lists.openembedded.org wrote:
> avahi, systemd-resolved and mDNSResponder (in meta-networking) can all
> provide Zeroconf services. Add a `ZEROCONF_DAEMON` option to select
> which of these will provide service via packagegroup-base-zeroconf.
> 
> Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
> ---
>  meta/recipes-core/packagegroups/packagegroup-base.bb | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-core/packagegroups/packagegroup-base.bb b/meta/recipes-core/packagegroups/packagegroup-base.bb
> index cb9d1f07af51..ac450fbdc9a7 100644
> --- a/meta/recipes-core/packagegroups/packagegroup-base.bb
> +++ b/meta/recipes-core/packagegroups/packagegroup-base.bb
> @@ -312,11 +312,14 @@ RDEPENDS:packagegroup-base-nfs = "\
>  RRECOMMENDS:packagegroup-base-nfs = "\
>      kernel-module-nfs "
>  
> +# Choose 'avahi-daemon', 'mdns' or 'systemd-resolved' as zeroconf-daemon
> +ZEROCONF_DAEMON ??= "${@bb.utils.contains('DISTRO_FEATURES', 'systemd-resolved', 'systemd-resolved', 'avahi-daemon', d)}"
>  SUMMARY:packagegroup-base-zeroconf = "Zeroconf support"
>  RDEPENDS:packagegroup-base-zeroconf = "\
> -    avahi-daemon"
> +    ${@ '' if d.getVar('ZEROCONF_DAEMON') == 'systemd-resolved' else d.getVar('ZEROCONF_DAEMON')} \
> +    "
>  RDEPENDS:packagegroup-base-zeroconf:append:libc-glibc = "\
> -    libnss-mdns \
> +    ${@ {'mdns':'mdns-libnss-mdns','avahi-daemon':'avahi-libnss-mdns','systemd-resolved':''}[d.getVar('ZEROCONF_DAEMON')]} \
>      "
>  
>  SUMMARY:packagegroup-base-ipv6 = "IPv6 support"

This has been sitting in master-next for too long. Various people on
the patch review calls have promised to reply to it but we've all been
struggling for the right reasoning and time to write that reply.

Basically, several of us are not convinced this is correct. The
challenge is that "zeroconf" means different things and the things
being switched between here aren't equivalent. They don't have the same
APIs and don't function in the same way, the similarities are very
loose. That contradicts the way we usually make selections like this.

That said, having stared at this just now, I can nearly convince myself
this is the right thing to do :/.

Can anyone suggest how this should be handled?

Cheers,

Richard