| Message ID | 20250215165545.1929-1-alex.kiernan@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v2] packagegroup-base: Add option to set zeroconf provider | expand |
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
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.
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
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...
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] > -=-=-=-=-=-=-=-=-=-=-=- >
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
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
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
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 > >
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...
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"
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(-)