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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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