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" <[email protected]> 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1065): https://lists.openembedded.org/g/openembedded-architecture/message/1065 Mute This Topic: https://lists.openembedded.org/mt/73131657/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
