On Mon, 30 Aug 2021, Robert P. J. Day wrote: > i was going to extend section 3.3.17, "Using Virtual Providers", > with an intro example using "udev" until i realized that that > example doesn't use the "virtual/" notation. so ... why not? is > there some distinction between other components that use the > "virtual/" prefix, but a reason that one does not specify: > > PROVIDES = "virtual/udev" > > rather than just: > > PROVIDES = "udev" > > and then use the corresponding PREFERRED_PROVIDER_virtual/udev > notation?
just to make sure folks understand what i'm getting at, the section: https://docs.yoctoproject.org/dev-manual/common-tasks.html#using-virtual-providers opens with, "Prior to a build, if you know that several different recipes provide the same functionality, you can use a virtual provider (i.e. virtual/*) as a placeholder for the actual provider." except there are cases where several different recipes provide the same functionality that *don't* incorporate the "virtual/" notation, so which ones merit that and which ones don't? (i mentioned "udev" being provided by both "eudev" and "systemd", for which i wrote an utterly brilliant explanation that i now realize isn't appropriate for that section.) in the simpler cases, you have recipes that have a new name that can now be used in place of the old, such that "stress-ng" provides "stress", so you don't have to mess with all your old images and packagegroups. and in situations like that, the "virtual/" notation would seem out of place. OTOH, well, virtual "kernel" and "bootloader" makes perfect sense as they represent a more abstract idea. so ... thoughts? even though "udev" does not use the "virtual/" notation, would it still fall under the category of "virtual provider"? if not, how would one describe it? rday
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#155479): https://lists.openembedded.org/g/openembedded-core/message/155479 Mute This Topic: https://lists.openembedded.org/mt/85245879/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
