[OE-core] [PATCH 2/2] kernel: user defined KERNEL_VERSION_PKG_NAME
Razvan Heghedus
razvan.heghedus at ni.com
Thu Jun 29 09:10:22 UTC 2017
On 06/28/2017 04:29 AM, Bruce Ashfield wrote:
>
>
> On Tue, Jun 27, 2017 at 5:15 AM, Razvan Heghedus
> <razvan.heghedus at ni.com <mailto:razvan.heghedus at ni.com>> wrote:
>
>
>
> On 06/26/2017 06:52 PM, Bruce Ashfield wrote:
>>
>>
>> On Wed, Jun 21, 2017 at 8:00 AM, Heghedus Razvan
>> <razvan.heghedus at ni.com <mailto:razvan.heghedus at ni.com>> wrote:
>>
>> Add possibility to set KERNEL_VERSION_PKG_NAME to a user
>> defined value.
>>
>> Signed-off-by: Heghedus Razvan <razvan.heghedus at ni.com
>> <mailto:razvan.heghedus at ni.com>>
>> ---
>> meta/classes/kernel.bbclass | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/classes/kernel.bbclass
>> b/meta/classes/kernel.bbclass
>> index 605c101e62..02728d5a86 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -28,12 +28,16 @@ INITRAMFS_IMAGE_BUNDLE ?= ""
>> # LINUX_VERSION which is a constant.
>> KERNEL_VERSION_NAME = "${@d.getVar('KERNEL_VERSION') or "
>> <mailto:$%7B at d.getVar%28%27KERNEL_VERSION%27%29or>"}"
>> KERNEL_VERSION_NAME[vardepvalue] = "${LINUX_VERSION}"
>> -KERNEL_VERSION_PKG_NAME =
>> "${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}"
>> -KERNEL_VERSION_PKG_NAME[vardepvalue] = "${LINUX_VERSION}"
>>
>> python __anonymous () {
>> import re
>>
>> + if d.getVar('USER_KERNEL_VERSION_PKG') is None :
>> + d.setVar('KERNEL_VERSION_PKG_NAME',
>> "${@legitimize_package_name(d.getVar('KERNEL_VERSION'))}")
>> + d.setVar('KERNEL_VERSION_PKG_NAME[vardepvalue]',
>> "${LINUX_VERSION}")
>> + else:
>> + d.setVar('KERNEL_VERSION_PKG_NAME',
>> "${@legitimize_package_name(d.getVar('USER_KERNEL_VERSION_PKG'))}")
>>
>>
>> This is introducing yet another variable that tweaks the already
>> complex setting of
>> the kernel version. Not to mention this code is already touchy
>> with respect to
>> parse time and rebuilding of the kernel.
>>
>> My concern is that if this is set, we are completely
>> disassociated with the source
>> code of the kernel.
>>
>> Where did you think this would be set ? local.conf ? distro
>> config ? somewhere else ?
>>
>> If we had a way to simply override KERNEL_VERSION, we wouldn't
>> need any extra
>> variables.
>>
>> Bruce
>>
>> +
>> # Merge KERNEL_IMAGETYPE and KERNEL_ALT_IMAGETYPE into
>> KERNEL_IMAGETYPES
>> type = d.getVar('KERNEL_IMAGETYPE') or ""
>> alttype = d.getVar('KERNEL_ALT_IMAGETYPE') or ""
>> --
>> 2.13.1
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> <mailto:Openembedded-core at lists.openembedded.org>
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
>>
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness
>> await thee at its end"
> I have setting the variable in the kernel recipe. I need a way to
> override the KERNEL_VERSION because I want the kernel packages
> name to contain only a part of the version or nothing at all.
> I need this for the the kernel upgrade stuff, because if the
> package name is something like: kernel-4.9.8-{static_string} then
> I couldn't upgrade to a version like:
> kernel-4.9.10-{static_string}, because they are two different
> packages. I wanted a simple way to be able to have the package
> name : kernel-4.9-{static_string}, then I could do the upgrade for
> the new minor updates of the kernel.
>
>
> I could have sworn this (upgrading) was already possible via the
> version string we
> are currently using. i.e. the PV is already picked up from the kernel
> source, and
> that should be doing the job.
>
> i.e. when I unpack my
> kernel-image-bzimage-4.10.15-yocto-standard_4.10.15+git0+4d929fac34_d2c1ed3c0c-r0_qemux86_64.ipk
> package, I see that it has:
>
> Version: 4.10.15+git0+4d929fac34_d2c1ed3c0c-r0
> but obviously has the general provides: Provides: kernel-image-bzimage
>
> So that should be upgradable based on the version ... sure they have
> different names, but the provides
> and versions take care of things.
>
> The versioning, ability to install multiple kernels, upgrades, etc,
> have really churned
> these variables making them a mess to read.
>
> I'm probably misunderstanding your use case and error, can you
> elaborate for me
> and/or provide a log ? I'm more of a kernel guy than a package format
> guy .. so
> I'm probably missing something obvious.
>
> Bruce
>
If I build a genericx86_64 core-image_sato without this patch, only with
the other patch which add the versions(only the parts that are in round
parenthesis) I have the following packages:
Package: kernel-4.10.9-yocto-standard
Version: 4.10.9+git0+ad2e885015_fe0fb8da3d-r0
Depends: kernel-image-4.10.9-yocto-standard (=
4.10.9+git0+ad2e885015_fe0fb8da3d-r0)
Provides: kernel-4.10.9-yocto-standard, kernel-base
Package: kernel-image-4.10.9-yocto-standard
Version: 4.10.9+git0+ad2e885015_fe0fb8da3d-r0
Depends: kernel-image-bzimage-4.10.9-yocto-standard (=
4.10.9+git0+ad2e885015_fe0fb8da3d-r0)
Provides: kernel-image
Package: kernel-module-6lowpan-4.10.9-yocto-standard
Version: 4.10.9+git0+ad2e885015_fe0fb8da3d-r0
Depends: kernel-4.10.9-yocto-standard (=
4.10.9+git0+ad2e885015_fe0fb8da3d-r0)
Provides: kernel-module-6lowpan
So the problem are the Depends field. We have the 4.10.9 part in the
dependents that is messing with the upgrade. If we want to do only some
minor update that doesn't change this value than everything is ok. It
works. But if we have a new value e.g. 4.10.10 than we couldn't do the
upgrade.
So that's why I came up with this patch to be able to modify the Depends
value to something like: kernel-image-4.10-yocto-standard, or even
kernel-image.
>
>
> This was the simple and cleanest way I could think of to achieve
> the my scenario. But if there is a better idea for this, let me know.
>
> --
>
> Razvan
>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
--
Razvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170629/7c5ab162/attachment-0002.html>
More information about the Openembedded-core
mailing list