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

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

[Alex Kiernan]

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"

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

[Quentin Schulz]

Hi Alex,

On 2/15/25 5:55 PM, 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.
> 

If I'm not mistaken, this seems to be fitting RPROVIDES usage?

What if we had something like

RPROVIDES:${PN}-resolved += "zeroconf-daemon"

in the systemd recipe

RPROVIDES:${PN}-libnss-mdns += "zeroconf-daemon"

in the mdns recipe and

RPROVIDES:${PN}-daemon += "zeroconf-daemon"

in the avahi-libnss-mdns recipe?

and then we simply RDEPENDS on zeroconf-daemon?

Does that work (haven't tested myself)? What do you think?

Cheers,
Quentin

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

[Alex Kiernan]

On Mon, Feb 17, 2025 at 10:32 AM Quentin Schulz
<quentin.schulz@cherry.de> wrote:
>
> Hi Alex,
>
> On 2/15/25 5:55 PM, 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.
> >
>
> If I'm not mistaken, this seems to be fitting RPROVIDES usage?
>

I guess I'm guilty of copying what was there (WIRELESS_DAEMON)

> What if we had something like
>
> RPROVIDES:${PN}-resolved += "zeroconf-daemon"
>
> in the systemd recipe
>
> RPROVIDES:${PN}-libnss-mdns += "zeroconf-daemon"
>
> in the mdns recipe and
>

This would be:

RPROVIDES:${PN} += "zeroconf-daemon"

> RPROVIDES:${PN}-daemon += "zeroconf-daemon"
>
> in the avahi-libnss-mdns recipe?
>

And the base avahi recipe here

> and then we simply RDEPENDS on zeroconf-daemon?
>
> Does that work (haven't tested myself)? What do you think?
>

And then selection via a PREFERRED_RPROVIDER:zeroconf-daemon = "..."

I guess I think it should work, though my concern is the interaction
between the daemon and the nss plugin, which is how I ended up down
this rabbit hole in the first place!

We seem to have very little usage of RPROVIDES (other than as a
migration mechanism) and PREFERRED_RPROVIDER in general.

-- 
Alex Kiernan

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

[Quentin Schulz]

Hi Alex,

On 2/17/25 12:16 PM, Alex Kiernan wrote:
> On Mon, Feb 17, 2025 at 10:32 AM Quentin Schulz
> <quentin.schulz@cherry.de> wrote:
>>
>> Hi Alex,
>>
>> On 2/15/25 5:55 PM, 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.
>>>
>>
>> If I'm not mistaken, this seems to be fitting RPROVIDES usage?
>>
> 
> I guess I'm guilty of copying what was there (WIRELESS_DAEMON)
> 

Fair enough, consistency is probably better here then :)

>> and then we simply RDEPENDS on zeroconf-daemon?
>>
>> Does that work (haven't tested myself)? What do you think?
>>
> 
> And then selection via a PREFERRED_RPROVIDER:zeroconf-daemon = "..."
> 
> I guess I think it should work, though my concern is the interaction
> between the daemon and the nss plugin, which is how I ended up down
> this rabbit hole in the first place!
> 
> We seem to have very little usage of RPROVIDES (other than as a
> migration mechanism) and PREFERRED_RPROVIDER in general.
> 

That makes sense if the packages are absolutely incompatible with each 
other. For example, for the WIRELESS_DAEMON case, you may want to have 
wpa-supplicant but probably could have iwd too in the same rootfs and 
let the user pick the one they want to use?

If we can have multiple zeroconf daemons, then that wouldn't be a good 
solution anyways.

Cheers,
Quentin

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

[Alex Kiernan]

On Mon, Feb 17, 2025 at 5:05 PM Quentin Schulz <quentin.schulz@cherry.de> wrote:
>
> Hi Alex,
>
> On 2/17/25 12:16 PM, Alex Kiernan wrote:
> > On Mon, Feb 17, 2025 at 10:32 AM Quentin Schulz
> > <quentin.schulz@cherry.de> wrote:
> >>
> >> Hi Alex,
> >>
> >> On 2/15/25 5:55 PM, 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.
> >>>
> >>
> >> If I'm not mistaken, this seems to be fitting RPROVIDES usage?
> >>
> >
> > I guess I'm guilty of copying what was there (WIRELESS_DAEMON)
> >
>
> Fair enough, consistency is probably better here then :)
>
> >> and then we simply RDEPENDS on zeroconf-daemon?
> >>
> >> Does that work (haven't tested myself)? What do you think?
> >>
> >
> > And then selection via a PREFERRED_RPROVIDER:zeroconf-daemon = "..."
> >
> > I guess I think it should work, though my concern is the interaction
> > between the daemon and the nss plugin, which is how I ended up down
> > this rabbit hole in the first place!
> >
> > We seem to have very little usage of RPROVIDES (other than as a
> > migration mechanism) and PREFERRED_RPROVIDER in general.
> >
>
> That makes sense if the packages are absolutely incompatible with each
> other. For example, for the WIRELESS_DAEMON case, you may want to have
> wpa-supplicant but probably could have iwd too in the same rootfs and
> let the user pick the one they want to use?
>
> If we can have multiple zeroconf daemons, then that wouldn't be a good
> solution anyways.
>

Technically you can (as this is a multicast socket), but actually
making it work properly isn't straightforward as you'd end up with two
daemons both announcing the host record. Pretty sure you can make it
work, which is different from wpa_supplicant/iwd (and I guess you
could even make those coexist if you had two wireless interfaces?),
but I'm not sure it's an out of the box configuration we should be
point folk at! libnss-mdns is a simple pick one or the other choice,
but that's enforced anyway because they end up colliding in the
filesystem.

Frankly it's a bit of mess...

-- 
Alex Kiernan

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

[Khem Raj]

On Mon, Feb 17, 2025 at 10:10 AM Alex Kiernan via
lists.openembedded.org <alex.kiernan=gmail.com@lists.openembedded.org>
wrote:
>
> On Mon, Feb 17, 2025 at 5:05 PM Quentin Schulz <quentin.schulz@cherry.de> wrote:
> >
> > Hi Alex,
> >
> > On 2/17/25 12:16 PM, Alex Kiernan wrote:
> > > On Mon, Feb 17, 2025 at 10:32 AM Quentin Schulz
> > > <quentin.schulz@cherry.de> wrote:
> > >>
> > >> Hi Alex,
> > >>
> > >> On 2/15/25 5:55 PM, 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.
> > >>>
> > >>
> > >> If I'm not mistaken, this seems to be fitting RPROVIDES usage?
> > >>
> > >
> > > I guess I'm guilty of copying what was there (WIRELESS_DAEMON)
> > >
> >
> > Fair enough, consistency is probably better here then :)
> >
> > >> and then we simply RDEPENDS on zeroconf-daemon?
> > >>
> > >> Does that work (haven't tested myself)? What do you think?
> > >>
> > >
> > > And then selection via a PREFERRED_RPROVIDER:zeroconf-daemon = "..."
> > >
> > > I guess I think it should work, though my concern is the interaction
> > > between the daemon and the nss plugin, which is how I ended up down
> > > this rabbit hole in the first place!
> > >
> > > We seem to have very little usage of RPROVIDES (other than as a
> > > migration mechanism) and PREFERRED_RPROVIDER in general.
> > >
> >
> > That makes sense if the packages are absolutely incompatible with each
> > other. For example, for the WIRELESS_DAEMON case, you may want to have
> > wpa-supplicant but probably could have iwd too in the same rootfs and
> > let the user pick the one they want to use?
> >
> > If we can have multiple zeroconf daemons, then that wouldn't be a good
> > solution anyways.
> >
>
> Technically you can (as this is a multicast socket), but actually
> making it work properly isn't straightforward as you'd end up with two
> daemons both announcing the host record. Pretty sure you can make it
> work, which is different from wpa_supplicant/iwd (and I guess you
> could even make those coexist if you had two wireless interfaces?),
> but I'm not sure it's an out of the box configuration we should be
> point folk at! libnss-mdns is a simple pick one or the other choice,
> but that's enforced anyway because they end up colliding in the
> filesystem.

I think sorting a sane default would be good for all. I am not too tied to any
one package.

>
> Frankly it's a bit of mess...
>
> --
> Alex Kiernan
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#211549): https://lists.openembedded.org/g/openembedded-core/message/211549
> Mute This Topic: https://lists.openembedded.org/mt/111202159/1997914
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

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

[Alex Kiernan]

On Mon, Feb 17, 2025 at 6:20 PM Khem Raj <raj.khem@gmail.com> wrote:
>
> On Mon, Feb 17, 2025 at 10:10 AM Alex Kiernan via
> lists.openembedded.org <alex.kiernan=gmail.com@lists.openembedded.org>
> wrote:
> >
> > On Mon, Feb 17, 2025 at 5:05 PM Quentin Schulz <quentin.schulz@cherry.de> wrote:
> > >
> > > Hi Alex,
> > >
> > > On 2/17/25 12:16 PM, Alex Kiernan wrote:
> > > > On Mon, Feb 17, 2025 at 10:32 AM Quentin Schulz
> > > > <quentin.schulz@cherry.de> wrote:
> > > >>
> > > >> Hi Alex,
> > > >>
> > > >> On 2/15/25 5:55 PM, 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.
> > > >>>
> > > >>
> > > >> If I'm not mistaken, this seems to be fitting RPROVIDES usage?
> > > >>
> > > >
> > > > I guess I'm guilty of copying what was there (WIRELESS_DAEMON)
> > > >
> > >
> > > Fair enough, consistency is probably better here then :)
> > >
> > > >> and then we simply RDEPENDS on zeroconf-daemon?
> > > >>
> > > >> Does that work (haven't tested myself)? What do you think?
> > > >>
> > > >
> > > > And then selection via a PREFERRED_RPROVIDER:zeroconf-daemon = "..."
> > > >
> > > > I guess I think it should work, though my concern is the interaction
> > > > between the daemon and the nss plugin, which is how I ended up down
> > > > this rabbit hole in the first place!
> > > >
> > > > We seem to have very little usage of RPROVIDES (other than as a
> > > > migration mechanism) and PREFERRED_RPROVIDER in general.
> > > >
> > >
> > > That makes sense if the packages are absolutely incompatible with each
> > > other. For example, for the WIRELESS_DAEMON case, you may want to have
> > > wpa-supplicant but probably could have iwd too in the same rootfs and
> > > let the user pick the one they want to use?
> > >
> > > If we can have multiple zeroconf daemons, then that wouldn't be a good
> > > solution anyways.
> > >
> >
> > Technically you can (as this is a multicast socket), but actually
> > making it work properly isn't straightforward as you'd end up with two
> > daemons both announcing the host record. Pretty sure you can make it
> > work, which is different from wpa_supplicant/iwd (and I guess you
> > could even make those coexist if you had two wireless interfaces?),
> > but I'm not sure it's an out of the box configuration we should be
> > point folk at! libnss-mdns is a simple pick one or the other choice,
> > but that's enforced anyway because they end up colliding in the
> > filesystem.
>
> I think sorting a sane default would be good for all. I am not too tied to any
> one package.
>

I think this gives sensible defaults... if you're a systemd user (with
systemd-networkd) you get systemd-resolved, else avahi, unless you
need to make it through Apple's bonjour conformance testing, in which
case you probably want mDNSResponder, but that's definitely an opt-in
choice (passing BCT is possible with the others, but the testing is so
painful, frankly going mDNSResponder is just easier).


> >
> > Frankly it's a bit of mess...
> >
> > --
> > Alex Kiernan
> >
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > View/Reply Online (#211549): https://lists.openembedded.org/g/openembedded-core/message/211549
> > Mute This Topic: https://lists.openembedded.org/mt/111202159/1997914
> > Group Owner: openembedded-core+owner@lists.openembedded.org
> > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >



--
Alex Kiernan

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

[Richard Purdie]

On Mon, 2025-02-17 at 11:16 +0000, Alex Kiernan via lists.openembedded.org wrote:
> On Mon, Feb 17, 2025 at 10:32 AM Quentin Schulz
> <quentin.schulz@cherry.de> wrote:
> > 
> > Hi Alex,
> > 
> > On 2/15/25 5:55 PM, 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.
> > > 
> > 
> > If I'm not mistaken, this seems to be fitting RPROVIDES usage?
> > 
> 
> I guess I'm guilty of copying what was there (WIRELESS_DAEMON)
> 
> > What if we had something like
> > 
> > RPROVIDES:${PN}-resolved += "zeroconf-daemon"
> > 
> > in the systemd recipe
> > 
> > RPROVIDES:${PN}-libnss-mdns += "zeroconf-daemon"
> > 
> > in the mdns recipe and
> > 
> 
> This would be:
> 
> RPROVIDES:${PN} += "zeroconf-daemon"
> 
> > RPROVIDES:${PN}-daemon += "zeroconf-daemon"
> > 
> > in the avahi-libnss-mdns recipe?
> > 
> 
> And the base avahi recipe here
> 
> > and then we simply RDEPENDS on zeroconf-daemon?
> > 
> > Does that work (haven't tested myself)? What do you think?
> > 
> 
> And then selection via a PREFERRED_RPROVIDER:zeroconf-daemon = "..."
> 
> I guess I think it should work, though my concern is the interaction
> between the daemon and the nss plugin, which is how I ended up down
> this rabbit hole in the first place!
> 
> We seem to have very little usage of RPROVIDES (other than as a
> migration mechanism) and PREFERRED_RPROVIDER in general.

I'd strongly suggest avoiding PREFERRED_RPROVIDER. It doesn't work how
people think it does and I wish I'd held my ground and never added the
thing. It works where you have something that can be provided by
multiple things even if several of them end up present, it doesn't
matter as long as you have at least one.

The reason there aren't many references to PREFERRED_RPROVIDER is
because what I suspect you're trying to do is usually handled with
VIRTUAL-RUNTIME_* variables. These lock in to specific configuration
choices explicitly.

They are pretty horrible and I wish we had a better way but they are
the best we've been able to come up with. I've had ideas on better
solutions but never any time to implement anything.

Cheers,

Richard

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

[Richard Purdie]

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

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

[Joshua Watt]

On Tue, May 20, 2025 at 7:39 AM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> 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?

Ya, I struggled with this one also. In my mind, the problem here is
that "zeroconf" is a pretty precise set of functionality that allows
you do to automatic network setup. The problem as I see it is that
each method of implementing that does so with wildly different and
generally incompatible userspace APIs (systemd/avahi/mdns-sd). The
problem is thusly that if all you truly cared about was just zeroconf,
then it doesn't matter which of these you chose (although, by that
token, why do we need a choice at all if they all do the same thing?),
but as soon as you want to write applications that use mDNS, it
matters greatly which mDNS provider you use.

As such, my suggestion is just to leave this as is. If you truly only
care about zeroconf, then use the packagegroup and you'll get it. If
you care about the mDNS API, *don't* use this to provide it. Packages
that need a specific API should pull in the correct one automatically,
or you can add it as a distro dependency, etc. It just doesn't quite
seem right to me to backdoor it though this packagegroup.

>
> Cheers,
>
> Richard
>
>

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

[Alex Kiernan]

On Tue, May 20, 2025 at 3:16 PM Joshua Watt <jpewhacker@gmail.com> wrote:
>
> On Tue, May 20, 2025 at 7:39 AM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > 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?
>
> Ya, I struggled with this one also. In my mind, the problem here is
> that "zeroconf" is a pretty precise set of functionality that allows
> you do to automatic network setup. The problem as I see it is that
> each method of implementing that does so with wildly different and
> generally incompatible userspace APIs (systemd/avahi/mdns-sd). The
> problem is thusly that if all you truly cared about was just zeroconf,
> then it doesn't matter which of these you chose (although, by that
> token, why do we need a choice at all if they all do the same thing?),
> but as soon as you want to write applications that use mDNS, it
> matters greatly which mDNS provider you use.
>
> As such, my suggestion is just to leave this as is. If you truly only
> care about zeroconf, then use the packagegroup and you'll get it. If
> you care about the mDNS API, *don't* use this to provide it. Packages
> that need a specific API should pull in the correct one automatically,
> or you can add it as a distro dependency, etc. It just doesn't quite
> seem right to me to backdoor it though this packagegroup.
>

If I explain how I got here, but then say I don't actually disagree
with this point of view!

I have a platform that needs to use mDNSResponder (i.e. needs to get
through the horror that is bonjour conformance testing[1]), but we
have zeroconf in the default list of DISTRO_FEATURES, so
packagegroup-base gets you packagegroup-base-zeroconf, which gets you
avahi.

But I guess I've made the assumption that zeroconf is about mdns and
how that happens, not how IPv4 link local addressing is done, which is
another of the zeroconf hats.

Maybe this is really a documentation problem and the zeroconf feature
is just IPv4LL addressing and not the entire networking soup of
https://en.wikipedia.org/wiki/Zero-configuration_networking?

[1] Yes, I know Avahi can pass, but getting a BCT pass is beyond painful...

-- 
Alex Kiernan