Hi all,

Giving my 2¢.

On Wed, Apr 22, 2020 at 09:10:42AM +0100, Richard Purdie wrote:

On Wed, 2020-04-22 at 08:21 +0100, Paul Barker wrote:

On Sun, 19 Apr 2020 18:04:34 +0100
"Richard Purdie" <richard.purdie@...> wrote:

Of the two I think using `${PN}` is the correct one otherwise you'd
get a clash between the package names when building with multilib (so
you get `X-bar` and `lib32-X-bar` for example instead of two packages
both named `X-bar`).

One solution is to use ${PN} or ${MLPREFIX} everywhere. The multilib
class exists mainly as we didn't want to go through every recipe and
mark things up that way, believing instead the code could automate it.

Indeed, and the thing is... it does not fix the original issue, so third
party layers not doing that will still have the same bug which is hard
to detect. Since we can't unforce it, that seems to not be the solution.

We've already got warnings for `${PN}` used in places where `${BPN}`
should really be used. Perhaps this is a case for something similar
like raising a warning if PACKAGES contains the value of PN as a
literal instead of using `${PN}`?

This isn't possible as we have a lot of recipes generating packages
with names that don't contain PN...

Also, this looks like a dangerous whack-a-mole. We know it breaks for
LICENSE, does it break for something else we haven't found yet, are we
going to forget on adding a warning once a new feature could have the
same bogus behavior?

It's like silencing the actual issue and giving us a false sense of safety.

Thanks for looking into the issue and resuming much better the issue
than in the book I sent as a bug report :)
Quentin