RDEPENDS:${PN}-lic and multilib

RDEPENDS:${PN}-lic and multilib

[Mike Crowe]

We've been successfully using the "lic-pkgs" image feature in order to
install licence information in our images for some time and we ensure that
the licences for header-only or static libraries are correctly included too
by adding RDEPENDS like:

 RDEPENDS:${PN}-lic += "boost-lic"

to the affected recipes in the absence of anything better[1].

I've just tried to build a multilib image with both Scarthgap and Dunfell
and discovered that this doesn't work. I get warnings:

 WARNING: lib32-lictest-1.0-r0 do_package: QA Issue: lib32-lictest package lib32-lictest-lic - suspicious values 'boost-lic' in RDEPENDS [multilib]
 WARNING: lib32-lictest-1.0-r0 do_package: QA Issue: lib32-lictest package lib32-lictest-dev - suspicious values 'boost-lic-dev' in RRECOMMENDS [multilib]
 WARNING: lib32-lictest-1.0-r0 do_package_qa: QA Issue: lib32-lictest-lic rdepends on boost-lic, but it isn't a build dependency? [build-deps]

The solver then complains that nothing provides boost-lic (because I'm not
building "boost", just "lib32-boost".)

If I change the recipe to instead say:

 RDEPENDS:${PN}-lic += "${MLPREFIX}boost-lic"

then the warnings go away and the image is generated correctly containing
lib32-boost-lic.

(I found that I needed to cleansstate both my test recipe and the image in
order to make the behaviour described above reproducible when switching
back and forth. Changes to RDEPENDS:${PN}-lic in the recipe alone didn't
seem to cause everything to be rebuilt correctly.)

RDEPENDS don't normally need to use ${MLPREFIX}. It looks like
ClassExtender's rename_packages automatically adds ${MLPREFIX} when
necessary to all the RDEPENDS overrides that are listed in PACKAGES. But
${PN}-lic isn't in PACKAGES so it doesn't get that treatment.

If I try to add ${PN}-lic to PACKAGES then I get:

 ERROR: Nothing RPROVIDES 'lib32-boost-lic'

Whilst I can add ${MLPREFIX} to each entry in DEPENDS:${PN}-lic it feels as
if I might be fixing this problem in the wrong way. Is there something else
I should be doing instead?

Thanks.

Mike.

[1] https://lists.openembedded.org/g/openembedded-core/message/156909