public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] why "PREFERRED_PROVIDER_udev" and not "PREFERRED_PROVIDER_virtual/udev"?
Date: Mon, 30 Aug 2021 04:11:50 -0400 (EDT)	[thread overview]
Message-ID: <8a9e42cd-7cb9-cca5-3a16-d33893de5fa@crashcourse.ca> (raw)
In-Reply-To: <16A0063E8A02B067.22970@lists.openembedded.org>

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

       reply	other threads:[~2021-08-30  8:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <16A0063E8A02B067.22970@lists.openembedded.org>
2021-08-30  8:11 ` Robert P. J. Day [this message]
2021-08-30  7:52 why "PREFERRED_PROVIDER_udev" and not "PREFERRED_PROVIDER_virtual/udev"? Robert P. J. Day
2021-08-30 16:09 ` [OE-core] " Khem Raj
2021-08-31  8:27   ` Robert P. J. Day
2021-08-31  9:24     ` Richard Purdie
2021-08-31  9:23 ` Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8a9e42cd-7cb9-cca5-3a16-d33893de5fa@crashcourse.ca \
    --to=rpjday@crashcourse.ca \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox