On Wed, 2020-04-22 at 08:21 +0100, Paul Barker wrote:
> On Sun, 19 Apr 2020 18:04:34 +0100
> "Richard Purdie" <richard.pur...@linuxfoundation.org> wrote:
>
> > I'm a bit worried about some of the mulitlib issues we've seen
> > recently. In particular we have a bug where license exclusion
> > doesn't
> > work properly in multilib builds, which is fairly serious.
> >
> > To dive into the details of what I found, as things stand today,
> > the
> > code sequence is:
> >
> > a) bb.event.RecipePreFinalise
> > b) bb.data.expandKeys()
> > c) base.bbclass anonymous python
> > d) multilib.bbclass anonymous python
> >
> > The mutlilib code does half the work in a) but delays half to d)
> > since
> > it has to happen after python key expansion, there is no way to
> > avoid
> > that.
> >
> > The issue is that there is code in base.bbclass's anonymous python
> > (step c) that assumes the package information in the datastore is
> > correct, yet it isn't under after d).
> >
> > For example if you set:
> >
> > PACKAGES += "X-bar"
> > LICENSE_${PN}-bar = "Y"
> > (and PN is X)
> >
> > then base.bbclass can't see the LICENSE value by iterating
> > PACKAGES.
> > Yes, you could argue PACKAGES should match the keys used but that
> > is
> > hard to enforce and really shouldn't be necessary.
>
> At first glance this appears to be a mismatch between PACKAGES and
> the
> override used on LICENSE. It should either be:
>
> PACKAGES += "X-bar"
> LICENSE_X-bar = "Y"
>
> or
>
> PACKAGES += "${PN}-bar"
> LICENSE_${PN}-bar = "Y"
>
> but mixing those is always going to lead to pain somewhere in my
> experience.
Right, mixing them definitely gives the worst possible behaviours.
Sadly we have recipes doing this today, with unpredictable side
effects. We have always said we don't support this but it does mostly
work and is hard to spot and even more painful to debug when it breaks.
> 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.
> 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...
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1057):
https://lists.openembedded.org/g/openembedded-architecture/message/1057
Mute This Topic: https://lists.openembedded.org/mt/73131657/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
