On Mon, Feb 17, 2025 at 6:20 PM Khem Raj <raj.k...@gmail.com> wrote: > > On Mon, Feb 17, 2025 at 10:10 AM Alex Kiernan via > lists.openembedded.org <alex.kiernan=gmail....@lists.openembedded.org> > wrote: > > > > On Mon, Feb 17, 2025 at 5:05 PM Quentin Schulz <quentin.sch...@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.sch...@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 > > > > > > -- Alex Kiernan
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#211626): https://lists.openembedded.org/g/openembedded-core/message/211626 Mute This Topic: https://lists.openembedded.org/mt/111202159/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
