(part of the nitpickiness of some of these questions stems from
that, in my updated courseware, i want to use actual examples out of,
say, the openembedded layer, and not just contrived examples involving
packages like "foo" and "bar". to that end, i want to be able to
explain why some recipes are written the way they are and, conversely,
to explain why some recipes might look weird.)

the bitbake manual has a reasonable explanation of
DEFAULT_PREFERENCE but there are examples in the OE layer that seem to
not be written as cleanly as they could be.

consider under recipes-devtools the two directories "pkgconfig" and
"pkgconf", and the respective .bb files:

- pkgconfig_git.bb
- pkgconf_1.6.3.bb

the pkgconfig recipe file does *not* contain a PROVIDES setting, while
pkgconfig_1.6.3.bb does:

PROVIDES += "pkgconfig"

so, given that, one expects that other recipes should have a
DEPENDency on "pkgconfig", which could be satisfied by either of
those.

however, oddly, the file pkgconf_1.6.3.bb contains the line:

DEFAULT_PREFERENCE = "-1"

which seems odd as there don't appear to be any other recipes that
provide pkgconfig, and AIUI, the default provider for any recipe is
the recipe with *exactly* the same name as the target -- in this case,
"pkgconfig".

so while that DEFAULT_PREFERENCE line doesn't hurt anything, in this
specific case (assuming i haven't overlooked any other recipes that
provide pkgconfig), that DEFAULT_PREFERENCE line is superfluous,
correct?

rday

On Sat, 8 Feb 2020, rpjday@... wrote:
... snip ...

which seems odd as there don't appear to be any other recipes that
provide pkgconfig, and AIUI, the default provider for any recipe is
the recipe with *exactly* the same name as the target -- in this case,
"pkgconfig".

...

also wanted to clarify, while the default provider of a dependency
is the recipe with *exactly* that name, i'm assuming (i think i
remember this from somewhere) that if you have a number of recipes
that all provide, say, "virtual/kernel", and you have an explicit
dependency of "virtual/kernel", you *must* supply a

PREFERRED_PROVIDER_virtual/kernel = ...

line, yes? as in, there's no weird processing to figure out which
recipe you'll be arbitrarily handed among the several that could be
used.

rday

On Sat, 2020-02-08 at 13:48 -0500, rpjday@... wrote:

On Sat, 8 Feb 2020, rpjday@... wrote:
... snip ...

which seems odd as there don't appear to be any other recipes that
provide pkgconfig, and AIUI, the default provider for any recipe is
the recipe with *exactly* the same name as the target -- in this
case,
"pkgconfig".

...

also wanted to clarify, while the default provider of a dependency
is the recipe with *exactly* that name, i'm assuming (i think i
remember this from somewhere) that if you have a number of recipes
that all provide, say, "virtual/kernel", and you have an explicit
dependency of "virtual/kernel", you *must* supply a

PREFERRED_PROVIDER_virtual/kernel = ...

line, yes? as in, there's no weird processing to figure out which
recipe you'll be arbitrarily handed among the several that could be
used.

The resolution code is deterministic (i.e. it might sort them) but
there is no specific default provider, no.

Cheers,

Richard

On Sat, 2020-02-08 at 13:31 -0500, rpjday@... wrote:

(part of the nitpickiness of some of these questions stems from
that, in my updated courseware, i want to use actual examples out of,
say, the openembedded layer, and not just contrived examples
involving
packages like "foo" and "bar". to that end, i want to be able to
explain why some recipes are written the way they are and,
conversely,
to explain why some recipes might look weird.)

the bitbake manual has a reasonable explanation of
DEFAULT_PREFERENCE but there are examples in the OE layer that seem
to
not be written as cleanly as they could be.

consider under recipes-devtools the two directories "pkgconfig"
and
"pkgconf", and the respective .bb files:

- pkgconfig_git.bb
- pkgconf_1.6.3.bb

the pkgconfig recipe file does *not* contain a PROVIDES setting,
while pkgconfig_1.6.3.bb does:

PROVIDES += "pkgconfig"

The above looks superfluous at a glance.

so, given that, one expects that other recipes should have a
DEPENDency on "pkgconfig", which could be satisfied by either of
those.

however, oddly, the file pkgconf_1.6.3.bb contains the line:

DEFAULT_PREFERENCE = "-1"

which seems odd as there don't appear to be any other recipes that
provide pkgconfig, and AIUI, the default provider for any recipe is
the recipe with *exactly* the same name as the target -- in this
case, "pkgconfig".

DEFAULT_PREFERENCE works against versions, not providers.
I'm not sure what that line is trying to do but I also suspect its superfluous.

so while that DEFAULT_PREFERENCE line doesn't hurt anything, in
this specific case (assuming i haven't overlooked any other recipes
that provide pkgconfig), that DEFAULT_PREFERENCE line is superfluous,
correct?

For different reasoning, yes :)

Cheers,

Richard

On Sat, 2020-02-08 at 13:31 -0500, rpjday@... wrote:

(part of the nitpickiness of some of these questions stems from
that, in my updated courseware, i want to use actual examples out of,
say, the openembedded layer, and not just contrived examples
involving
packages like "foo" and "bar". to that end, i want to be able to
explain why some recipes are written the way they are and,
conversely,
to explain why some recipes might look weird.)

the bitbake manual has a reasonable explanation of
DEFAULT_PREFERENCE but there are examples in the OE layer that seem
to
not be written as cleanly as they could be.

consider under recipes-devtools the two directories "pkgconfig"
and
"pkgconf", and the respective .bb files:

- pkgconfig_git.bb
- pkgconf_1.6.3.bb

the pkgconfig recipe file does *not* contain a PROVIDES setting,
while pkgconfig_1.6.3.bb does:

PROVIDES += "pkgconfig"

It doesn't, pkgconf_1.6.3.bb does, which is quite different and it then
makes sense.

Cheers,

Richard

On Mon, 10 Feb 2020, Richard Purdie wrote:

On Sat, 2020-02-08 at 13:31 -0500, rpjday@... wrote:

consider under recipes-devtools the two directories "pkgconfig"
and "pkgconf", and the respective .bb files:

- pkgconfig_git.bb
- pkgconf_1.6.3.bb

the pkgconfig recipe file does *not* contain a PROVIDES setting,
while pkgconfig_1.6.3.bb does:

PROVIDES += "pkgconfig"

The above looks superfluous at a glance.

sorry, i mistyped the above, i should have written:

"the pkgconfig recipe file does *not* contain a PROVIDES setting,
while pkgconf_1.6.3.bb does:"

so that PROVIDES line *would* be necessary, yes? (just not the "+="
part). my apologies for reproducing incorrectly.

rday

On Mon, 10 Feb 2020, Richard Purdie wrote:

On Sat, 2020-02-08 at 13:48 -0500, rpjday@... wrote:

On Sat, 8 Feb 2020, rpjday@... wrote:
... snip ...

which seems odd as there don't appear to be any other recipes that
provide pkgconfig, and AIUI, the default provider for any recipe is
the recipe with *exactly* the same name as the target -- in this
case,
"pkgconfig".

...

also wanted to clarify, while the default provider of a dependency
is the recipe with *exactly* that name, i'm assuming (i think i
remember this from somewhere) that if you have a number of recipes
that all provide, say, "virtual/kernel", and you have an explicit
dependency of "virtual/kernel", you *must* supply a

PREFERRED_PROVIDER_virtual/kernel = ...

line, yes? as in, there's no weird processing to figure out which
recipe you'll be arbitrarily handed among the several that could be
used.

The resolution code is deterministic (i.e. it might sort them) but
there is no specific default provider, no.

ah, so if you don't specify a PREFERRED_PROVIDER, then *some*
provider will ultimately be selected, is that it? you just won't have
any gurarantee which one it will be.

rday