| 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
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(-)