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.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) > > > 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#211557): https://lists.openembedded.org/g/openembedded-core/message/211557 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] -=-=-=-=-=-=-=-=-=-=-=-