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

["Zoltan Boszormenyi" <zboszor@pr.hu>]

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.


> 
> 
> Thanks,
> Jon
> 
>>> For me, a kernel-image-bzimage-x.y.z is built.
>>>
>>>> kernel-image-5.13.13+g91381833a4e2-5.13.13+git0+91381833a4-r0.imx8mp_lpddr4_evk
>>>>    *
>>>>    * Solution 1:
>>>>    *   - do not ask to install a package providing kernel-modules
>>>>
>>>> Reverting this commit does solve it, but I would like to understand
>>>> more on what should be done in order to use this new mechanism you've
>>>> introduced. Do you have any suggestion on what should be adapted in
>>>> the BSP layer to have those RDEPENDS properly resolved?
>>>>
>>>> Package manager is set for me to IPK.
>>>>
>>>> Setting KERNEL_SPLIT_MODULES="1" does not solve the issue.
>>>
>>> This is the default.
>>> But setting it to "0" won't change whether the
>>> kernel-image-image-x.y.z subpackage gets built or not.
>>>
>>
>>
>> --
>> Regards,
>> Andrey.
>>
>>
>>
>>
>>
>> 
>>