Re: [OE-core] [PATCH v4 3/4] kernel.bbclass: Use full versions for inter-package dependencies

["Richard Purdie" <richard.purdie@linuxfoundation.org>]

On Tue, 2021-08-31 at 06:28 +0200, Zoltan Boszormenyi via lists.openembedded.org
wrote:
> 2021. 08. 30. 21:51 keltezéssel, Jon Mason írta:
> > On Mon, Aug 30, 2021 at 6:26 AM Andrey Zhizhikin <andrey.z@gmail.com> wrote:
> > > 
> > > On Mon, Aug 30, 2021 at 12:06 PM Böszörményi Zoltán <zboszor@gmail.com> wrote:
> > > > 
> > > > 2021. 08. 30. 11:30 keltezéssel, Andrey Zhizhikin írta:
> > > > > Hello Zoltan,
> > > > > 
> > > > > On Fri, Aug 27, 2021 at 9:37 AM Zoltan Boszormenyi via
> > > > > lists.openembedded.org <zboszor=pr.hu@lists.openembedded.org> wrote:
> > > > > > From: Zoltán Böszörményi <zboszor@gmail.com>
> > > > > > 
> > > > > > If the kernel configuration enables module signing but no key
> > > > > > is provided, then the kernel generates one during the kernel build.
> > > > > > 
> > > > > > The current runtime-dependency references (with only package names
> > > > > > without full versions) allow mixed package installations from different
> > > > > > rebuilds of the same kernel version.
> > > > > > 
> > > > > > This creates an issue because then the modules either don't work
> > > > > > or taint the kernel.
> > > > > > 
> > > > > > Tighten RDEPENDS with the full package version, i.e. use (= ${EXTENDPKGV})
> > > > > > markers for inter-package dependencies.
> > > > > > 
> > > > > > The kernel will pull in the kernel-modules subpackage of the same
> > > > > > exact version automatically if KERNEL_SPLIT_MODULES="0" is set.
> > > > > > Otherwise the situation is the same as with the old default with
> > > > > > one subpackage per kernel module where they have to be upgraded
> > > > > > manually.
> > > > > > 
> > > > > > Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
> > > > > > ---
> > > > > >    meta/classes/kernel.bbclass | 13 +++++++------
> > > > > >    1 file changed, 7 insertions(+), 6 deletions(-)
> > > > > > 
> > > > > I'm seeing errors during the do_rootfs() with this patch applied,
> > > > > there are few messages like this:
> > > > > 
> > > > >    * Solver encountered 1 problem(s):
> > > > >    * Problem 1/1:
> > > > >    *   - package kernel-module-libchacha-5.13.13+g91381833a4e2-5.13.13+git0+91381833a4-r0.imx8mp_lpddr4_evk
> > > > > requires kernel-5.13.13+g91381833a4e2, but none of the providers can
> > > > > be installed
> > > > >    *   - package kernel-modules-5.13.13+git0+91381833a4-r0.imx8mp_lpddr4_evk
> > > > > requires kernel-module-libchacha-5.13.13+g91381833a4e2, but none of
> > > > > the providers can be installed
> > > > >    *   - package kernel-5.13.13+g91381833a4e2-5.13.13+git0+91381833a4-r0.imx8mp_lpddr4_evk
> > > > > requires kernel-image-5.13.13+g91381833a4e2 =
> > > > > 5.13.13+git0+91381833a4-r0, but none of the providers can be installed
> > > > >    *   - conflicting requests
> > > > >    *   - nothing provides kernel-image-image-5.13.13+g91381833a4e2 =
> > > > > 5.13.13+gitAUTOINC+91381833a4-r0 needed by
> > > > 
> > > > This seems to be the problem.
> > > > Is there a "kernel-image-image-5.13.13" built from your kernel recipe?
> > > 
> > > Yes, it is produced. But for some reasons opkg cannot resolve it
> > > during the do_rootfs(), which is quite odd.
> > 
> > I'm seeing the same issue.  All of the BSPs that I set the kernel to
> > not be 5.13 (i.e., 5.10, 5.4, etc) fail.  For example,
> > https://gitlab.com/jonmason00/meta-arm/-/jobs/1544819828
> > If I set the PACKAGE_CLASS to be rpm instead of ipk, everything works
> > as expected.  So, there must be some difference in the dep calculation
> > in ipk.
> 
> Interesting.
> 
> Can you both please try setting KERNEL_SPLIT_MODULES="0" in your kernel recipe?
> In my testing, it works for both ipk and rpm properly.
> 
> I am thinking that probably the full version dependency should
> only be used in the KERNEL_SPLIT_MODULES="0" case.
> This can be easily tested, unlike the packaging method.

Ross noticed it was failing with unexpanded AUTOINC references. That made me
realise that using the unexpanded version of the variable in these cases might
help. I've sent out that patch for review/testing.

Cheers,

Richard