From: "Zoltan Boszormenyi" <zboszor@pr.hu>
To: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>,
zboszor@gmail.com
Subject: Re: [OE-core] [PATCH 5/6] kernel.bbclass: Use full versions for inter-package dependencies
Date: Mon, 23 Aug 2021 15:48:14 +0200 [thread overview]
Message-ID: <9010ef07-e7ac-341c-05e5-df6b575e02db@pr.hu> (raw)
In-Reply-To: <CADkTA4NbBHutpYeYte6dh1BjjPHSGF4KBvG4XV_PO8tARDXHtA@mail.gmail.com>
2021. 08. 23. 15:38 keltezéssel, Bruce Ashfield írta:
> On Mon, Aug 23, 2021 at 9:30 AM Böszörményi Zoltán <zboszor@pr.hu> wrote:
>>
>> 2021. 08. 23. 15:03 keltezéssel, Bruce Ashfield írta:
>>> On Mon, Aug 23, 2021 at 8:23 AM Zoltan Boszormenyi via
>>> lists.openembedded.org <zboszor=pr.hu@lists.openembedded.org> wrote:
>>>>
>>>> From: Zoltán Böszörményi <zboszor@gmail.com>
>>>>
>>>> Some Yocto users do use package repositories and sometimes the PR
>>>> value is forgotten. Use full versions for inter-package dependencies
>>>> for the kernel subpackages.
>>>
>>> Can you expand this commit message ?
>>
>> I will send a new version with the expanded message.
>>
>>> What is the observable problem
>>> with the full versions not being in the rdpends ?
>>
>> Currently the kernel creates such subpackages:
>>
>> kernel
>> kernel-x.y.z
>> kernel-image-x.y.z
>> kernel-image-bzimage-x.y.z
>> kernel-modules-x.y.z
>>
>> and in the split modules case, a lot of
>>
>> kernel-module-*-x.y.z
>>
>> RDEPENDS currently only references the package names.
>>
>> The issue I observe is this: I have enabled kernel module signing
>> but I don't provide a key, so the kernel will generate one at
>> every rebuild.
>>
>> You get the idea what problem this can make if there's a
>> rebuild:
>>
>> x.y.z-r0.0 -> x.y.z-r1.0 (in which case the PR value was duly changed)
>> or
>> x.y.z-r0.0 -> x.y.z-r0.1 (where not)
>>
>> It's actually indifferent, but the same issue occurs if
>> only the kernel-image-bzimage is upgraded: the modules either
>> won't work or taint the kernel.
>
> Your second example is similar to the times I've seen some module
> issues as well, and honestly, I can't recall if it was solved in a
> similar way to this (I don't have access to my old repos from Wind
> River any more).
>
> But that does make sense to me, and the details you have in this
> follow up, make a nice commit explanation.
>
> While opkg may not handle the situation you describe as well as RPM,
> we should make sure that the full version doesn't cause issues with
> the package generation or standard image creation.
You can bet it doesn't. I have the same patch in a Sumo-based distro
where we still use ipk and opkg and there's no issue in either image
generation or package upgrades. Only that there's no "installonly"
knowledge in opkg (unlike dnf) so old kernel packages have to be
manually cleaned up there.
>
> Cheers,
>
> Bruce
>
>>
>> This scenario is currently valid in the package manager because
>> of the versionless RDEPENDS.
>>
>>>
>>> I've run many different package feeds with different kernels and
>>> modules, and haven't run into anything on this front, in my experience
>>> the extended version in the package depends/provides causes issues
>>> with some package managers .. so we'd need the testing for this
>>> documented/provided so we could ensure that there are no hidden
>>> issues.
>>>
>>> Bruce
>>>
>>>
>>>>
>>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
>>>> ---
>>>> meta/classes/kernel.bbclass | 13 +++++++------
>>>> 1 file changed, 7 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>>>> index 6dc5387a9b..9ec7daa17a 100644
>>>> --- a/meta/classes/kernel.bbclass
>>>> +++ b/meta/classes/kernel.bbclass
>>>> @@ -91,17 +91,18 @@ python __anonymous () {
>>>> kname = d.getVar('KERNEL_PACKAGE_NAME') or "kernel"
>>>> imagedest = d.getVar('KERNEL_IMAGEDEST')
>>>>
>>>> + fullver = d.getVar('EXTENDPKGV')
>>>> for type in types.split():
>>>> if bb.data.inherits_class('nopackages', d):
>>>> continue
>>>> typelower = type.lower()
>>>> d.appendVar('PACKAGES', ' %s-image-%s' % (kname, typelower))
>>>> d.setVar('FILES:' + kname + '-image-' + typelower, '/' + imagedest + '/' + type + '-${KERNEL_VERSION_NAME}' + ' /' + imagedest + '/' + type)
>>>> - d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s' % (kname, typelower))
>>>> + d.appendVar('RDEPENDS:%s-image' % kname, ' %s-image-%s (= %s)' % (kname, typelower, fullver))
>>>> splitmods = d.getVar("KERNEL_SPLIT_MODULES")
>>>> if splitmods != '1':
>>>> - d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules' % kname)
>>>> - d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' %s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
>>>> + d.appendVar('RDEPENDS:%s-image' % kname, ' %s-modules (= %s)' % (kname, fullver))
>>>> + d.appendVar('RDEPENDS:%s-image-%s' % (kname, typelower), ' %s-modules-${KERNEL_VERSION_PKG_NAME} (= %s)' % (kname, fullver))
>>>> d.setVar('PKG:%s-modules' % kname, '%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
>>>> d.appendVar('RPROVIDES:%s-modules' % kname, '%s-modules-${KERNEL_VERSION_PKG_NAME}' % kname)
>>>>
>>>> @@ -628,12 +629,12 @@ FILES:${KERNEL_PACKAGE_NAME}-image = ""
>>>> FILES:${KERNEL_PACKAGE_NAME}-dev = "/boot/System.map* /boot/Module.symvers* /boot/config* ${KERNEL_SRC_PATH} ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
>>>> FILES:${KERNEL_PACKAGE_NAME}-vmlinux = "/boot/vmlinux-${KERNEL_VERSION_NAME}"
>>>> FILES:${KERNEL_PACKAGE_NAME}-modules = ""
>>>> -RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base"
>>>> +RDEPENDS:${KERNEL_PACKAGE_NAME} = "${KERNEL_PACKAGE_NAME}-base (= ${EXTENDPKGV})"
>>>> # Allow machines to override this dependency if kernel image files are
>>>> # not wanted in images as standard
>>>> -RDEPENDS:${KERNEL_PACKAGE_NAME}-base ?= "${KERNEL_PACKAGE_NAME}-image"
>>>> +RDEPENDS:${KERNEL_PACKAGE_NAME}-base ?= "${KERNEL_PACKAGE_NAME}-image (= ${EXTENDPKGV})"
>>>> PKG:${KERNEL_PACKAGE_NAME}-image = "${KERNEL_PACKAGE_NAME}-image-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
>>>> -RDEPENDS:${KERNEL_PACKAGE_NAME}-image += "${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux', '${KERNEL_PACKAGE_NAME}-vmlinux', '', d)}"
>>>> +RDEPENDS:${KERNEL_PACKAGE_NAME}-image += "${@oe.utils.conditional('KERNEL_IMAGETYPE', 'vmlinux', '${KERNEL_PACKAGE_NAME}-vmlinux (= ${EXTENDPKGV})', '', d)}"
>>>> PKG:${KERNEL_PACKAGE_NAME}-base = "${KERNEL_PACKAGE_NAME}-${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
>>>> RPROVIDES:${KERNEL_PACKAGE_NAME}-base += "${KERNEL_PACKAGE_NAME}-${KERNEL_VERSION}"
>>>> ALLOW_EMPTY:${KERNEL_PACKAGE_NAME} = "1"
>>>> --
>>>> 2.31.1
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
>
>
>
>
next prev parent reply other threads:[~2021-08-23 13:48 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-23 12:23 Kernel and RPM related bbclass changes Zoltan Boszormenyi
2021-08-23 12:23 ` [PATCH 1/6] package_rpm.bbclass: Handle posttrans scriptlets Zoltan Boszormenyi
2021-08-23 12:34 ` [OE-core] " Alexander Kanavin
2021-08-23 13:14 ` Zoltan Boszormenyi
2021-08-23 13:23 ` Richard Purdie
2021-08-23 13:42 ` Zoltan Boszormenyi
2021-08-23 12:23 ` [PATCH 2/6] kernel-module-split.bbclass: Support zstd-compressed modules Zoltan Boszormenyi
2021-08-23 12:23 ` [PATCH 3/6] kernel-module-split.bbclass: Allow opt-out of split kernel modules Zoltan Boszormenyi
2021-08-23 12:55 ` [OE-core] " Bruce Ashfield
2021-08-23 13:18 ` Zoltan Boszormenyi
2021-08-23 13:27 ` Bruce Ashfield
2021-08-23 13:31 ` Zoltan Boszormenyi
2021-08-23 13:35 ` Bruce Ashfield
[not found] ` <169DF0BA24F74A88.27647@lists.openembedded.org>
2021-08-23 12:56 ` Bruce Ashfield
2021-08-23 12:23 ` [PATCH 4/6] kernel.bbclass: Adapt to KERNEL_SPLIT_MODULES != "1" case Zoltan Boszormenyi
2021-08-23 12:23 ` [PATCH 5/6] kernel.bbclass: Use full versions for inter-package dependencies Zoltan Boszormenyi
2021-08-23 13:03 ` [OE-core] " Bruce Ashfield
2021-08-23 13:29 ` Zoltan Boszormenyi
2021-08-23 13:38 ` Bruce Ashfield
2021-08-23 13:48 ` Zoltan Boszormenyi [this message]
2021-08-23 12:23 ` [PATCH 6/6] Support zstd-compressed squashfs and cpio initramfs Zoltan Boszormenyi
2021-08-23 14:47 ` Kernel related bbclass changes Zoltan Boszormenyi
2021-08-23 14:47 ` [PATCH v2 1/4] kernel-module-split.bbclass: Support zstd-compressed modules Zoltan Boszormenyi
2021-08-23 14:47 ` [PATCH v2 2/4] Allow opt-out of split kernel modules Zoltan Boszormenyi
2021-08-23 14:47 ` [PATCH v2 3/4] kernel.bbclass: Use full versions for inter-package dependencies Zoltan Boszormenyi
2021-08-23 14:47 ` [PATCH v2 4/4] Support zstd-compressed squashfs and cpio initramfs Zoltan Boszormenyi
2021-08-23 14:54 ` Kernel related bbclass changes Zoltan Boszormenyi
2021-08-27 7:37 ` Kernel and image " Zoltan Boszormenyi
2021-08-27 7:37 ` [PATCH v4 1/4] kernel-module-split.bbclass: Support zstd-compressed modules Zoltan Boszormenyi
2021-08-27 7:37 ` [PATCH v4 2/4] Allow opt-out of split kernel modules Zoltan Boszormenyi
2021-08-27 7:37 ` [PATCH v4 3/4] kernel.bbclass: Use full versions for inter-package dependencies Zoltan Boszormenyi
2021-08-30 9:30 ` [OE-core] " Andrey Zhizhikin
2021-08-30 10:06 ` Zoltan Boszormenyi
[not found] ` <b75df7be-03d8-e454-60b8-1651fc935ca5@gmail.com>
2021-08-30 10:25 ` Andrey Zhizhikin
2021-08-30 19:51 ` Jon Mason
2021-08-31 4:28 ` Zoltan Boszormenyi
2021-08-31 13:32 ` Richard Purdie
2021-08-31 13:54 ` Andrey Zhizhikin
2021-08-27 7:37 ` [PATCH v4 4/4] Support zstd-compressed squashfs and cpio initramfs Zoltan Boszormenyi
2021-08-23 14:54 ` [PATCH v3 1/4] kernel-module-split.bbclass: Support zstd-compressed modules Zoltan Boszormenyi
2021-08-23 14:54 ` [PATCH v3 2/4] Allow opt-out of split kernel modules Zoltan Boszormenyi
2021-08-23 14:54 ` [PATCH v3 3/4] kernel.bbclass: Use full versions for inter-package dependencies Zoltan Boszormenyi
2021-08-23 14:54 ` [PATCH v3 4/4] Support zstd-compressed squashfs and cpio initramfs Zoltan Boszormenyi
2021-08-26 12:04 ` [OE-core] " Richard Purdie
2021-08-27 7:24 ` Zoltan Boszormenyi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9010ef07-e7ac-341c-05e5-df6b575e02db@pr.hu \
--to=zboszor@pr.hu \
--cc=bruce.ashfield@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=zboszor@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox