[PATCH 1/2] kernel: add package version in dependencies for kernel packages

[PATCH 1/2] kernel: add package version in dependencies for kernel packages

[Heghedus Razvan]

Make all dependencies from kernel family packages which depend
on another kernel related package to depend on the same version.
This creates a consistent state where kernel, kernel images and
kernel modules have the same version, making a kernel upgrade
leading to upgrades of the image and modules.

The upgrade works only if the KERNEL_VERSION_PKG_NAME remains
the same for the newer versions.

Signed-off-by: Heghedus Razvan <razvan.heghedus@ni.com>
---
 meta/classes/kernel-module-split.bbclass  |  7 ++++---
 meta/classes/kernel.bbclass               | 15 +++++++++------
 meta/recipes-kernel/linux/linux-yocto.inc |  4 ++++
 3 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass b/meta/classes/kernel-module-split.bbclass
index 5e10dcf735..e247e66901 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -33,7 +33,7 @@ PACKAGESPLITFUNCS_prepend = "split_kernel_module_packages "
 KERNEL_MODULES_META_PACKAGE ?= "kernel-modules"
 
 KERNEL_MODULE_PACKAGE_PREFIX ?= ""
-KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
+KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION_PKG_NAME}"
 KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1"
 
 python split_kernel_module_packages () {
@@ -114,6 +114,7 @@ python split_kernel_module_packages () {
             for dep in vals["depends"].split(","):
                 on = legitimize_package_name(dep)
                 dependency_pkg = format % on
+                dependency_pkg += ' ${@get_full_package_version(d)}'
                 modinfo_deps.append(dependency_pkg)
         for dep in modinfo_deps:
             if not dep in rdepends:
@@ -138,10 +139,10 @@ python split_kernel_module_packages () {
     postinst = d.getVar('pkg_postinst_modules')
     postrm = d.getVar('pkg_postrm_modules')
 
-    modules = do_split_packages(d, root='${nonarch_base_libdir}/modules', file_regex=module_regex, output_pattern=module_pattern, description='%s kernel module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, extra_depends='kernel-%s' % (d.getVar("KERNEL_VERSION")))
+    modules = do_split_packages(d, root='${nonarch_base_libdir}/modules', file_regex=module_regex, output_pattern=module_pattern, description='%s kernel module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, extra_depends='kernel-%s %s' % (d.getVar("KERNEL_VERSION_PKG_NAME"), get_full_package_version(d)))
     if modules:
         metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE')
-        d.appendVar('RDEPENDS_' + metapkg, ' '+' '.join(modules))
+        d.appendVar('RDEPENDS_' + metapkg, ' '+' '.join(['{0} {1}'.format(module, get_full_package_version(d)) for module in modules]))
 
     # If modules-load.d and modprobe.d are empty at this point, remove them to
     # avoid warnings. removedirs only raises an OSError if an empty
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 7a134d5c29..605c101e62 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -55,7 +55,7 @@ python __anonymous () {
 
         d.setVar('FILES_kernel-image-' + typelower, '/' + imagedest + '/' + type + '-${KERNEL_VERSION_NAME}')
 
-        d.appendVar('RDEPENDS_kernel-image', ' ' + 'kernel-image-' + typelower)
+        d.appendVar('RDEPENDS_kernel-image', ' ' + 'kernel-image-' + typelower + ' ${@get_full_package_version(d)}')
 
         d.setVar('PKG_kernel-image-' + typelower, 'kernel-image-' + typelower + '-${KERNEL_VERSION_PKG_NAME}')
 
@@ -493,14 +493,17 @@ FILES_kernel-image = ""
 FILES_kernel-dev = "/boot/System.map* /boot/Module.symvers* /boot/config* ${KERNEL_SRC_PATH} ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
 FILES_kernel-vmlinux = "/boot/vmlinux-${KERNEL_VERSION_NAME}"
 FILES_kernel-modules = ""
-RDEPENDS_kernel = "kernel-base"
+RDEPENDS_kernel = "kernel-base ${@get_full_package_version(d)}"
 # Allow machines to override this dependency if kernel image files are
 # not wanted in images as standard
-RDEPENDS_kernel-base ?= "kernel-image"
-PKG_kernel-image = "kernel-image-${@legitimize_package_name('${KERNEL_VERSION}')}"
+RDEPENDS_kernel-base ?= "kernel-image ${@get_full_package_version(d)}"
+PKG_kernel-image = "kernel-image-${KERNEL_VERSION_PKG_NAME}"
 RDEPENDS_kernel-image += "${@base_conditional('KERNEL_IMAGETYPE', 'vmlinux', 'kernel-vmlinux', '', d)}"
-PKG_kernel-base = "kernel-${@legitimize_package_name('${KERNEL_VERSION}')}"
-RPROVIDES_kernel-base += "kernel-${KERNEL_VERSION}"
+PKG_kernel-base = "kernel-${KERNEL_VERSION_PKG_NAME}"
+RPROVIDES_kernel-base += "kernel-${KERNEL_VERSION_PKG_NAME}"
+PKG_kernel-vmlinux = "kernel-vmlinux-${KERNEL_VERSION_PKG_NAME}"
+PKG_kernel-modules = "kernel-modules-${KERNEL_VERSION_PKG_NAME}"
+PKG_kernel-dev = "kernel-dev-${KERNEL_VERSION_PKG_NAME}"
 ALLOW_EMPTY_kernel = "1"
 ALLOW_EMPTY_kernel-base = "1"
 ALLOW_EMPTY_kernel-image = "1"
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc b/meta/recipes-kernel/linux/linux-yocto.inc
index 637506a2a8..c3d1284ad2 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -67,3 +67,7 @@ do_install_append(){
 addtask kernel_version_sanity_check after do_kernel_metadata do_kernel_checkout before do_compile
 addtask validate_branches before do_patch after do_kernel_checkout
 addtask kernel_configcheck after do_configure before do_compile
+
+def get_full_package_version(d):
+    return "(= " + d.getVar("PKGV") + "-" + d.getVar("PKGR") + ")"
+
-- 
2.13.1

[PATCH 2/2] kernel: user defined KERNEL_VERSION_PKG_NAME

[Heghedus Razvan]

Add possibility to set KERNEL_VERSION_PKG_NAME to a user
defined value.

Signed-off-by: Heghedus Razvan <razvan.heghedus@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 ""}"
 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'))}")
+
     # 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

Re: [PATCH 2/2] kernel: user defined KERNEL_VERSION_PKG_NAME

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 2364 bytes --]

On Wed, Jun 21, 2017 at 8:00 AM, Heghedus Razvan <razvan.heghedus@ni.com>
wrote:

> Add possibility to set KERNEL_VERSION_PKG_NAME to a user
> defined value.
>
> Signed-off-by: Heghedus Razvan <razvan.heghedus@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 ""}"
>  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@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 3754 bytes --]

Re: [PATCH 2/2] kernel: user defined KERNEL_VERSION_PKG_NAME

[Razvan Heghedus]

[-- Attachment #1: Type: text/plain, Size: 3591 bytes --]



On 06/26/2017 06:52 PM, Bruce Ashfield wrote:
>
>
> On Wed, Jun 21, 2017 at 8:00 AM, Heghedus Razvan 
> <razvan.heghedus@ni.com <mailto:razvan.heghedus@ni.com>> wrote:
>
>     Add possibility to set KERNEL_VERSION_PKG_NAME to a user
>     defined value.
>
>     Signed-off-by: Heghedus Razvan <razvan.heghedus@ni.com
>     <mailto:razvan.heghedus@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 ""}"
>      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@lists.openembedded.org
>     <mailto:Openembedded-core@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.

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


[-- Attachment #2: Type: text/html, Size: 6601 bytes --]

Re: [PATCH 2/2] kernel: user defined KERNEL_VERSION_PKG_NAME

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 4514 bytes --]

On Tue, Jun 27, 2017 at 5:15 AM, Razvan Heghedus <razvan.heghedus@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@ni.com>
> wrote:
>
>> Add possibility to set KERNEL_VERSION_PKG_NAME to a user
>> defined value.
>>
>> Signed-off-by: Heghedus Razvan <razvan.heghedus@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 "
>> <$%7B@d.getVar('KERNEL_VERSION')or>"}"
>>  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@lists.openembedded.org
>> 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



>
> 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"

[-- Attachment #2: Type: text/html, Size: 8473 bytes --]

Re: [PATCH 2/2] kernel: user defined KERNEL_VERSION_PKG_NAME

[Razvan Heghedus]

[-- Attachment #1: Type: text/plain, Size: 6737 bytes --]



On 06/28/2017 04:29 AM, Bruce Ashfield wrote:
>
>
> On Tue, Jun 27, 2017 at 5:15 AM, Razvan Heghedus 
> <razvan.heghedus@ni.com <mailto:razvan.heghedus@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@ni.com <mailto:razvan.heghedus@ni.com>> wrote:
>>
>>         Add possibility to set KERNEL_VERSION_PKG_NAME to a user
>>         defined value.
>>
>>         Signed-off-by: Heghedus Razvan <razvan.heghedus@ni.com
>>         <mailto:razvan.heghedus@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@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@lists.openembedded.org
>>         <mailto:Openembedded-core@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


[-- Attachment #2: Type: text/html, Size: 14657 bytes --]

Re: [PATCH 2/2] kernel: user defined KERNEL_VERSION_PKG_NAME

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 7282 bytes --]

On Thu, Jun 29, 2017 at 5:10 AM, Razvan Heghedus <razvan.heghedus@ni.com>
wrote:

>
>
> On 06/28/2017 04:29 AM, Bruce Ashfield wrote:
>
>
>
> On Tue, Jun 27, 2017 at 5:15 AM, Razvan Heghedus <razvan.heghedus@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@ni.com>
>> wrote:
>>
>>> Add possibility to set KERNEL_VERSION_PKG_NAME to a user
>>> defined value.
>>>
>>> Signed-off-by: Heghedus Razvan <razvan.heghedus@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 "
>>> <$%7B@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@lists.openembedded.org
>>> 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-y
> octo-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_fe0fb8d
> a3d-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.
>

That's the point I'm trying to make.

Patch 1/2 adds the depends, but there's no way to disable it. Without
defining the variable
that you have in patch 2/2, you can't upgrade the kernel packages .. which
makes it not only
a new variable, but a new requirement when working with the kernel
recipes/packages.

People have been upgrading the kernel before either of these patches (I
can't say that
I do very often .. but I know that users of the commercially supported
distros do) .. unless
it has been inadvertently broken, or there are more patches floating around
that I've not
seen.

what is the upgrade behaviour with neither of these patches applied ? ..
that's the behaviour that
I'm most concerned about maintaining.

Also, if we were to introduce something like this, the series needs to have
documentation
updates along with it .. or we'll surely forget to document it and catch
people by surprise :(

Bruce


>
>> 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
>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 16215 bytes --]

Re: [PATCH 2/2] kernel: user defined KERNEL_VERSION_PKG_NAME

[Razvan Heghedus]

[-- Attachment #1: Type: text/plain, Size: 10533 bytes --]



On 06/29/2017 04:06 PM, Bruce Ashfield wrote:
>
>
> On Thu, Jun 29, 2017 at 5:10 AM, Razvan Heghedus 
> <razvan.heghedus@ni.com <mailto:razvan.heghedus@ni.com>> wrote:
>
>
>
>     On 06/28/2017 04:29 AM, Bruce Ashfield wrote:
>>
>>
>>     On Tue, Jun 27, 2017 at 5:15 AM, Razvan Heghedus
>>     <razvan.heghedus@ni.com <mailto:razvan.heghedus@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@ni.com <mailto:razvan.heghedus@ni.com>> wrote:
>>>
>>>             Add possibility to set KERNEL_VERSION_PKG_NAME to a user
>>>             defined value.
>>>
>>>             Signed-off-by: Heghedus Razvan <razvan.heghedus@ni.com
>>>             <mailto:razvan.heghedus@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@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@lists.openembedded.org
>>>             <mailto:Openembedded-core@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.
>
>
> That's the point I'm trying to make.
>
> Patch 1/2 adds the depends, but there's no way to disable it. Without 
> defining the variable
> that you have in patch 2/2, you can't upgrade the kernel packages .. 
> which makes it not only
> a new variable, but a new requirement when working with the kernel 
> recipes/packages.
>
> People have been upgrading the kernel before either of these patches 
> (I can't say that
> I do very often .. but I know that users of the commercially supported 
> distros do) .. unless
> it has been inadvertently broken, or there are more patches floating 
> around that I've not
> seen.
>
> what is the upgrade behaviour with neither of these patches applied ? 
> .. that's the behaviour that
> I'm most concerned about maintaining.
>
> Also, if we were to introduce something like this, the series needs to 
> have documentation
> updates along with it .. or we'll surely forget to document it and 
> catch people by surprise :(
>
> Bruce

You misunderstood the first patch. It only appends the version to the 
packages in the Depends field. E.g (from the pyro branch):

Package: kernel-4.10.17-yocto-standard
Version: 4.10.17+git0+4b89f331d4_6648a34e00-r0
Depends: kernel-image-4.10.17-yocto-standard
Provides: kernel-4.10.17-yocto-standard, kernel-base

Package: kernel-image-4.10.17-yocto-standard
Version: 4.10.17+git0+4b89f331d4_6648a34e00-r0
Depends: kernel-image-bzimage-4.10.17-yocto-standard
Provides: kernel-image

Package: kernel-module-6lowpan-4.10.17-yocto-standard
Version: 4.10.17+git0+4b89f331d4_6648a34e00-r0
Depends: kernel-4.10.17-yocto-standard
Provides: kernel-module-6lowpan

As you can see the difference from the last email was only the versions 
in the Depends field.
About the upgrades, I only manage to upgrade the kernel only for new 
revisions version, from kernel-4.10.17-yocto-standard version 
4.10.17+git0+4b89f331d4_6648a34e00-r0 to kernel-4.10.17-yocto-standard 
version 4.10.17+git0+4b89f331d4_6648a34e00-r1. I tried to do an upgrade 
from kernel-4.10.15-yocto-standard to kernel-4.10.17-yocto-standard, but 
it failed (For the upgrade tests I used ipk format, might be the new 
opkg solver).

About the other distros based on OE, maybe they have some custom recipe 
for the kernel and somehow achieve the the same behaviour as this patch, 
or use rpm/deb, or the have custom scripts for the kernel and modules 
upgrades, or something else, idk.

The idea of these patches is to have a simple and easy way to do a 
kernel upgrade(with the kernel image and installed kernel modules), 
because now, when you want to upgrade the kernel you need to manually do 
the upgrade for the kernel-image and the modules.

>>
>>         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
>
>
>
>
> -- 
> "Thou shalt not follow the NULL pointer, for chaos and madness await 
> thee at its end"

-- 

Razvan


[-- Attachment #2: Type: text/html, Size: 26601 bytes --]

Re: [PATCH 2/2] kernel: user defined KERNEL_VERSION_PKG_NAME

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 9791 bytes --]

Sorry for the slow reply. I was on vacation last week and didn't get back
to this.

Once I've waded through some email, I'll circle back and have a closer look.

Bruce

On Mon, Jul 3, 2017 at 10:36 AM, Razvan Heghedus <razvan.heghedus@ni.com>
wrote:

>
>
> On 06/29/2017 04:06 PM, Bruce Ashfield wrote:
>
>
>
> On Thu, Jun 29, 2017 at 5:10 AM, Razvan Heghedus <razvan.heghedus@ni.com>
> wrote:
>
>>
>>
>> On 06/28/2017 04:29 AM, Bruce Ashfield wrote:
>>
>>
>>
>> On Tue, Jun 27, 2017 at 5:15 AM, Razvan Heghedus <razvan.heghedus@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@ni.com
>>> > wrote:
>>>
>>>> Add possibility to set KERNEL_VERSION_PKG_NAME to a user
>>>> defined value.
>>>>
>>>> Signed-off-by: Heghedus Razvan <razvan.heghedus@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 "
>>>> <$%7B@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@lists.openembedded.org
>>>> 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-y
>> octo-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_fe0fb8d
>> a3d-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.
>>
>
> That's the point I'm trying to make.
>
> Patch 1/2 adds the depends, but there's no way to disable it. Without
> defining the variable
> that you have in patch 2/2, you can't upgrade the kernel packages .. which
> makes it not only
> a new variable, but a new requirement when working with the kernel
> recipes/packages.
>
> People have been upgrading the kernel before either of these patches (I
> can't say that
> I do very often .. but I know that users of the commercially supported
> distros do) .. unless
> it has been inadvertently broken, or there are more patches floating
> around that I've not
> seen.
>
> what is the upgrade behaviour with neither of these patches applied ? ..
> that's the behaviour that
> I'm most concerned about maintaining.
>
> Also, if we were to introduce something like this, the series needs to
> have documentation
> updates along with it .. or we'll surely forget to document it and catch
> people by surprise :(
>
> Bruce
>
>
> You misunderstood the first patch. It only appends the version to the
> packages in the Depends field. E.g (from the pyro branch):
>
> Package: kernel-4.10.17-yocto-standard
> Version: 4.10.17+git0+4b89f331d4_6648a34e00-r0
> Depends: kernel-image-4.10.17-yocto-standard
> Provides: kernel-4.10.17-yocto-standard, kernel-base
>
> Package: kernel-image-4.10.17-yocto-standard
> Version: 4.10.17+git0+4b89f331d4_6648a34e00-r0
> Depends: kernel-image-bzimage-4.10.17-yocto-standard
> Provides: kernel-image
>
> Package: kernel-module-6lowpan-4.10.17-yocto-standard
> Version: 4.10.17+git0+4b89f331d4_6648a34e00-r0
> Depends: kernel-4.10.17-yocto-standard
> Provides: kernel-module-6lowpan
>
> As you can see the difference from the last email was only the versions in
> the Depends field.
> About the upgrades, I only manage to upgrade the kernel only for new
> revisions version, from kernel-4.10.17-yocto-standard version
> 4.10.17+git0+4b89f331d4_6648a34e00-r0 to kernel-4.10.17-yocto-standard
> version 4.10.17+git0+4b89f331d4_6648a34e00-r1. I tried to do an upgrade
> from kernel-4.10.15-yocto-standard to kernel-4.10.17-yocto-standard, but it
> failed (For the upgrade tests I used ipk format, might be the new opkg
> solver).
>
> About the other distros based on OE, maybe they have some custom recipe
> for the kernel and somehow achieve the the same behaviour as this patch, or
> use rpm/deb, or the have custom scripts for the kernel and modules
> upgrades, or something else, idk.
>
> The idea of these patches is to have a simple and easy way to do a kernel
> upgrade(with the kernel image and installed kernel modules), because now,
> when you want to upgrade the kernel you need to manually do the upgrade for
> the kernel-image and the modules.
>
>
>
>>
>>> 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
>>
>>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end"
>
>
> --
>
> Razvan
>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 25920 bytes --]

Re: [PATCH 1/2] kernel: add package version in dependencies for kernel packages

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 6913 bytes --]

On Wed, Jun 21, 2017 at 8:00 AM, Heghedus Razvan <razvan.heghedus@ni.com>
wrote:

> Make all dependencies from kernel family packages which depend
> on another kernel related package to depend on the same version.
> This creates a consistent state where kernel, kernel images and
> kernel modules have the same version, making a kernel upgrade
> leading to upgrades of the image and modules.
>
> The upgrade works only if the KERNEL_VERSION_PKG_NAME remains
> the same for the newer versions.
>
> Signed-off-by: Heghedus Razvan <razvan.heghedus@ni.com>
> ---
>  meta/classes/kernel-module-split.bbclass  |  7 ++++---
>  meta/classes/kernel.bbclass               | 15 +++++++++------
>  meta/recipes-kernel/linux/linux-yocto.inc |  4 ++++
>  3 files changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/meta/classes/kernel-module-split.bbclass
> b/meta/classes/kernel-module-split.bbclass
> index 5e10dcf735..e247e66901 100644
> --- a/meta/classes/kernel-module-split.bbclass
> +++ b/meta/classes/kernel-module-split.bbclass
> @@ -33,7 +33,7 @@ PACKAGESPLITFUNCS_prepend =
> "split_kernel_module_packages "
>  KERNEL_MODULES_META_PACKAGE ?= "kernel-modules"
>
>  KERNEL_MODULE_PACKAGE_PREFIX ?= ""
> -KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
> +KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION_PKG_NAME}"
>  KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1"
>
>  python split_kernel_module_packages () {
> @@ -114,6 +114,7 @@ python split_kernel_module_packages () {
>              for dep in vals["depends"].split(","):
>                  on = legitimize_package_name(dep)
>                  dependency_pkg = format % on
> +                dependency_pkg += ' ${@get_full_package_version(d)}'
>                  modinfo_deps.append(dependency_pkg)
>          for dep in modinfo_deps:
>              if not dep in rdepends:
> @@ -138,10 +139,10 @@ python split_kernel_module_packages () {
>      postinst = d.getVar('pkg_postinst_modules')
>      postrm = d.getVar('pkg_postrm_modules')
>
> -    modules = do_split_packages(d, root='${nonarch_base_libdir}/modules',
> file_regex=module_regex, output_pattern=module_pattern, description='%s
> kernel module', postinst=postinst, postrm=postrm, recursive=True,
> hook=frob_metadata, extra_depends='kernel-%s' %
> (d.getVar("KERNEL_VERSION")))
> +    modules = do_split_packages(d, root='${nonarch_base_libdir}/modules',
> file_regex=module_regex, output_pattern=module_pattern, description='%s
> kernel module', postinst=postinst, postrm=postrm, recursive=True,
> hook=frob_metadata, extra_depends='kernel-%s %s' %
> (d.getVar("KERNEL_VERSION_PKG_NAME"), get_full_package_version(d)))
>      if modules:
>          metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE')
> -        d.appendVar('RDEPENDS_' + metapkg, ' '+' '.join(modules))
> +        d.appendVar('RDEPENDS_' + metapkg, ' '+' '.join(['{0}
> {1}'.format(module, get_full_package_version(d)) for module in modules]))
>
>      # If modules-load.d and modprobe.d are empty at this point, remove
> them to
>      # avoid warnings. removedirs only raises an OSError if an empty
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 7a134d5c29..605c101e62 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -55,7 +55,7 @@ python __anonymous () {
>
>          d.setVar('FILES_kernel-image-' + typelower, '/' + imagedest + '/'
> + type + '-${KERNEL_VERSION_NAME}')
>
> -        d.appendVar('RDEPENDS_kernel-image', ' ' + 'kernel-image-' +
> typelower)
> +        d.appendVar('RDEPENDS_kernel-image', ' ' + 'kernel-image-' +
> typelower + ' ${@get_full_package_version(d)}')
>
>          d.setVar('PKG_kernel-image-' + typelower, 'kernel-image-' +
> typelower + '-${KERNEL_VERSION_PKG_NAME}')
>
> @@ -493,14 +493,17 @@ FILES_kernel-image = ""
>  FILES_kernel-dev = "/boot/System.map* /boot/Module.symvers* /boot/config*
> ${KERNEL_SRC_PATH} ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
>  FILES_kernel-vmlinux = "/boot/vmlinux-${KERNEL_VERSION_NAME}"
>  FILES_kernel-modules = ""
> -RDEPENDS_kernel = "kernel-base"
> +RDEPENDS_kernel = "kernel-base ${@get_full_package_version(d)}"
>

Is that really supposed to be a space, between kernel-base and the package
version
call ? I guess so, since I see the same thing below in the
RDEPENDS_kernel-base
line below .. but it just reads strange to me.  i.e. if that's a RDEPENDS,
where is the
package get_full_package_version(d) created ?

Are you trying to set a generic versionless RDEPENDS and a versioned one
that doesn't
contain 'kernel-' in the name ?


>  # Allow machines to override this dependency if kernel image files are
>  # not wanted in images as standard
> -RDEPENDS_kernel-base ?= "kernel-image"
> -PKG_kernel-image = "kernel-image-${@legitimize_package_name('${KERNEL_
> VERSION}')}"
> +RDEPENDS_kernel-base ?= "kernel-image ${@get_full_package_version(d)}"
> +PKG_kernel-image = "kernel-image-${KERNEL_VERSION_PKG_NAME}"
>  RDEPENDS_kernel-image += "${@base_conditional('KERNEL_IMAGETYPE',
> 'vmlinux', 'kernel-vmlinux', '', d)}"
> -PKG_kernel-base = "kernel-${@legitimize_package_
> name('${KERNEL_VERSION}')}"
> -RPROVIDES_kernel-base += "kernel-${KERNEL_VERSION}"
> +PKG_kernel-base = "kernel-${KERNEL_VERSION_PKG_NAME}"
> +RPROVIDES_kernel-base += "kernel-${KERNEL_VERSION_PKG_NAME}"
> +PKG_kernel-vmlinux = "kernel-vmlinux-${KERNEL_VERSION_PKG_NAME}"
>
+PKG_kernel-modules = "kernel-modules-${KERNEL_VERSION_PKG_NAME}"
> +PKG_kernel-dev = "kernel-dev-${KERNEL_VERSION_PKG_NAME}"
>  ALLOW_EMPTY_kernel = "1"
>  ALLOW_EMPTY_kernel-base = "1"
>  ALLOW_EMPTY_kernel-image = "1"
> diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
> b/meta/recipes-kernel/linux/linux-yocto.inc
> index 637506a2a8..c3d1284ad2 100644
> --- a/meta/recipes-kernel/linux/linux-yocto.inc
> +++ b/meta/recipes-kernel/linux/linux-yocto.inc
> @@ -67,3 +67,7 @@ do_install_append(){
>  addtask kernel_version_sanity_check after do_kernel_metadata
> do_kernel_checkout before do_compile
>  addtask validate_branches before do_patch after do_kernel_checkout
>  addtask kernel_configcheck after do_configure before do_compile
> +
> +def get_full_package_version(d):
> +    return "(= " + d.getVar("PKGV") + "-" + d.getVar("PKGR") + ")"
>

This doesn't belong in linux-yocto.inc, since it is called in
kernel.bbclass. It needs to be in the base
class and have a namespace that indicates it is specific to the kernel.

Bruce


> +
> --
> 2.13.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 9295 bytes --]

Re: [PATCH 1/2] kernel: add package version in dependencies for kernel packages

[Razvan Heghedus]

[-- Attachment #1: Type: text/plain, Size: 8257 bytes --]



On 06/26/2017 06:50 PM, Bruce Ashfield wrote:
>
>
> On Wed, Jun 21, 2017 at 8:00 AM, Heghedus Razvan 
> <razvan.heghedus@ni.com <mailto:razvan.heghedus@ni.com>> wrote:
>
>     Make all dependencies from kernel family packages which depend
>     on another kernel related package to depend on the same version.
>     This creates a consistent state where kernel, kernel images and
>     kernel modules have the same version, making a kernel upgrade
>     leading to upgrades of the image and modules.
>
>     The upgrade works only if the KERNEL_VERSION_PKG_NAME remains
>     the same for the newer versions.
>
>     Signed-off-by: Heghedus Razvan <razvan.heghedus@ni.com
>     <mailto:razvan.heghedus@ni.com>>
>     ---
>      meta/classes/kernel-module-split.bbclass  |  7 ++++---
>      meta/classes/kernel.bbclass               | 15 +++++++++------
>      meta/recipes-kernel/linux/linux-yocto.inc |  4 ++++
>      3 files changed, 17 insertions(+), 9 deletions(-)
>
>     diff --git a/meta/classes/kernel-module-split.bbclass
>     b/meta/classes/kernel-module-split.bbclass
>     index 5e10dcf735..e247e66901 100644
>     --- a/meta/classes/kernel-module-split.bbclass
>     +++ b/meta/classes/kernel-module-split.bbclass
>     @@ -33,7 +33,7 @@ PACKAGESPLITFUNCS_prepend =
>     "split_kernel_module_packages "
>      KERNEL_MODULES_META_PACKAGE ?= "kernel-modules"
>
>      KERNEL_MODULE_PACKAGE_PREFIX ?= ""
>     -KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
>     +KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION_PKG_NAME}"
>      KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1"
>
>      python split_kernel_module_packages () {
>     @@ -114,6 +114,7 @@ python split_kernel_module_packages () {
>                  for dep in vals["depends"].split(","):
>                      on = legitimize_package_name(dep)
>                      dependency_pkg = format % on
>     +                dependency_pkg += ' ${@get_full_package_version(d)}'
>                      modinfo_deps.append(dependency_pkg)
>              for dep in modinfo_deps:
>                  if not dep in rdepends:
>     @@ -138,10 +139,10 @@ python split_kernel_module_packages () {
>          postinst = d.getVar('pkg_postinst_modules')
>          postrm = d.getVar('pkg_postrm_modules')
>
>     -    modules = do_split_packages(d,
>     root='${nonarch_base_libdir}/modules', file_regex=module_regex,
>     output_pattern=module_pattern, description='%s kernel module',
>     postinst=postinst, postrm=postrm, recursive=True,
>     hook=frob_metadata, extra_depends='kernel-%s' %
>     (d.getVar("KERNEL_VERSION")))
>     +    modules = do_split_packages(d,
>     root='${nonarch_base_libdir}/modules', file_regex=module_regex,
>     output_pattern=module_pattern, description='%s kernel module',
>     postinst=postinst, postrm=postrm, recursive=True,
>     hook=frob_metadata, extra_depends='kernel-%s %s' %
>     (d.getVar("KERNEL_VERSION_PKG_NAME"), get_full_package_version(d)))
>          if modules:
>              metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE')
>     -        d.appendVar('RDEPENDS_' + metapkg, ' '+' '.join(modules))
>     +        d.appendVar('RDEPENDS_' + metapkg, ' '+' '.join(['{0}
>     {1}'.format(module, get_full_package_version(d)) for module in
>     modules]))
>
>          # If modules-load.d and modprobe.d are empty at this point,
>     remove them to
>          # avoid warnings. removedirs only raises an OSError if an empty
>     diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>     index 7a134d5c29..605c101e62 100644
>     --- a/meta/classes/kernel.bbclass
>     +++ b/meta/classes/kernel.bbclass
>     @@ -55,7 +55,7 @@ python __anonymous () {
>
>              d.setVar('FILES_kernel-image-' + typelower, '/' +
>     imagedest + '/' + type + '-${KERNEL_VERSION_NAME}')
>
>     -        d.appendVar('RDEPENDS_kernel-image', ' ' +
>     'kernel-image-' + typelower)
>     +        d.appendVar('RDEPENDS_kernel-image', ' ' +
>     'kernel-image-' + typelower + ' ${@get_full_package_version(d)}')
>
>              d.setVar('PKG_kernel-image-' + typelower, 'kernel-image-'
>     + typelower + '-${KERNEL_VERSION_PKG_NAME}')
>
>     @@ -493,14 +493,17 @@ FILES_kernel-image = ""
>      FILES_kernel-dev = "/boot/System.map* /boot/Module.symvers*
>     /boot/config* ${KERNEL_SRC_PATH}
>     ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
>      FILES_kernel-vmlinux = "/boot/vmlinux-${KERNEL_VERSION_NAME}"
>      FILES_kernel-modules = ""
>     -RDEPENDS_kernel = "kernel-base"
>     +RDEPENDS_kernel = "kernel-base ${@get_full_package_version(d)}"
>
>
> Is that really supposed to be a space, between kernel-base and the 
> package version
> call ? I guess so, since I see the same thing below in the 
> RDEPENDS_kernel-base
> line below .. but it just reads strange to me.  i.e. if that's a 
> RDEPENDS, where is the
> package get_full_package_version(d) created ?
>
Yes, the space is supposed to be there. If it's inconvenient here, it 
can be moved in the string returned by get_full_package_version()
> Are you trying to set a generic versionless RDEPENDS and a versioned 
> one that doesn't
> contain 'kernel-' in the name ?
This will create a versioned RDEPENDS. The syntax for a versioned 
package is: "package_name (= package_version)". This only append the 
version to the current value.
>
>      # Allow machines to override this dependency if kernel image
>     files are
>      # not wanted in images as standard
>     -RDEPENDS_kernel-base ?= "kernel-image"
>     -PKG_kernel-image =
>     "kernel-image-${@legitimize_package_name('${KERNEL_VERSION}')}"
>     +RDEPENDS_kernel-base ?= "kernel-image
>     ${@get_full_package_version(d)}"
>     +PKG_kernel-image = "kernel-image-${KERNEL_VERSION_PKG_NAME}"
>      RDEPENDS_kernel-image += "${@base_conditional('KERNEL_IMAGETYPE',
>     'vmlinux', 'kernel-vmlinux', '', d)}"
>     -PKG_kernel-base =
>     "kernel-${@legitimize_package_name('${KERNEL_VERSION}')}"
>     -RPROVIDES_kernel-base += "kernel-${KERNEL_VERSION}"
>     +PKG_kernel-base = "kernel-${KERNEL_VERSION_PKG_NAME}"
>     +RPROVIDES_kernel-base += "kernel-${KERNEL_VERSION_PKG_NAME}"
>     +PKG_kernel-vmlinux = "kernel-vmlinux-${KERNEL_VERSION_PKG_NAME}"
>
>     +PKG_kernel-modules = "kernel-modules-${KERNEL_VERSION_PKG_NAME}"
>     +PKG_kernel-dev = "kernel-dev-${KERNEL_VERSION_PKG_NAME}"
>      ALLOW_EMPTY_kernel = "1"
>      ALLOW_EMPTY_kernel-base = "1"
>      ALLOW_EMPTY_kernel-image = "1"
>     diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
>     b/meta/recipes-kernel/linux/linux-yocto.inc
>     index 637506a2a8..c3d1284ad2 100644
>     --- a/meta/recipes-kernel/linux/linux-yocto.inc
>     +++ b/meta/recipes-kernel/linux/linux-yocto.inc
>     @@ -67,3 +67,7 @@ do_install_append(){
>      addtask kernel_version_sanity_check after do_kernel_metadata
>     do_kernel_checkout before do_compile
>      addtask validate_branches before do_patch after do_kernel_checkout
>      addtask kernel_configcheck after do_configure before do_compile
>     +
>     +def get_full_package_version(d):
>     +    return "(= " + d.getVar("PKGV") + "-" + d.getVar("PKGR") + ")"
>
>
> This doesn't belong in linux-yocto.inc, since it is called in 
> kernel.bbclass. It needs to be in the base
> class and have a namespace that indicates it is specific to the kernel.
>
Yeah, you're right, this shouldn't be in linux-yocto.inc. I will move it 
to the base class, but I need some info about namespace thing, because I 
don't recall reading about it in documentations.
> Bruce
>
>     +
>     --
>     2.13.1
>
>     --
>     _______________________________________________
>     Openembedded-core mailing list
>     Openembedded-core@lists.openembedded.org
>     <mailto:Openembedded-core@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"

-- 

Razvan


[-- Attachment #2: Type: text/html, Size: 13803 bytes --]

Re: [PATCH 1/2] kernel: add package version in dependencies for kernel packages

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 8787 bytes --]

On Tue, Jun 27, 2017 at 4:51 AM, Razvan Heghedus <razvan.heghedus@ni.com>
wrote:

>
>
> On 06/26/2017 06:50 PM, Bruce Ashfield wrote:
>
>
>
> On Wed, Jun 21, 2017 at 8:00 AM, Heghedus Razvan <razvan.heghedus@ni.com>
> wrote:
>
>> Make all dependencies from kernel family packages which depend
>> on another kernel related package to depend on the same version.
>> This creates a consistent state where kernel, kernel images and
>> kernel modules have the same version, making a kernel upgrade
>> leading to upgrades of the image and modules.
>>
>> The upgrade works only if the KERNEL_VERSION_PKG_NAME remains
>> the same for the newer versions.
>>
>> Signed-off-by: Heghedus Razvan <razvan.heghedus@ni.com>
>> ---
>>  meta/classes/kernel-module-split.bbclass  |  7 ++++---
>>  meta/classes/kernel.bbclass               | 15 +++++++++------
>>  meta/recipes-kernel/linux/linux-yocto.inc |  4 ++++
>>  3 files changed, 17 insertions(+), 9 deletions(-)
>>
>> diff --git a/meta/classes/kernel-module-split.bbclass
>> b/meta/classes/kernel-module-split.bbclass
>> index 5e10dcf735..e247e66901 100644
>> --- a/meta/classes/kernel-module-split.bbclass
>> +++ b/meta/classes/kernel-module-split.bbclass
>> @@ -33,7 +33,7 @@ PACKAGESPLITFUNCS_prepend =
>> "split_kernel_module_packages "
>>  KERNEL_MODULES_META_PACKAGE ?= "kernel-modules"
>>
>>  KERNEL_MODULE_PACKAGE_PREFIX ?= ""
>> -KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
>> +KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION_PKG_NAME}"
>>  KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1"
>>
>>  python split_kernel_module_packages () {
>> @@ -114,6 +114,7 @@ python split_kernel_module_packages () {
>>              for dep in vals["depends"].split(","):
>>                  on = legitimize_package_name(dep)
>>                  dependency_pkg = format % on
>> +                dependency_pkg += ' ${@get_full_package_version(d)}'
>>                  modinfo_deps.append(dependency_pkg)
>>          for dep in modinfo_deps:
>>              if not dep in rdepends:
>> @@ -138,10 +139,10 @@ python split_kernel_module_packages () {
>>      postinst = d.getVar('pkg_postinst_modules')
>>      postrm = d.getVar('pkg_postrm_modules')
>>
>> -    modules = do_split_packages(d, root='${nonarch_base_libdir}/modules',
>> file_regex=module_regex, output_pattern=module_pattern, description='%s
>> kernel module', postinst=postinst, postrm=postrm, recursive=True,
>> hook=frob_metadata, extra_depends='kernel-%s' %
>> (d.getVar("KERNEL_VERSION")))
>> +    modules = do_split_packages(d, root='${nonarch_base_libdir}/modules',
>> file_regex=module_regex, output_pattern=module_pattern, description='%s
>> kernel module', postinst=postinst, postrm=postrm, recursive=True,
>> hook=frob_metadata, extra_depends='kernel-%s %s' %
>> (d.getVar("KERNEL_VERSION_PKG_NAME"), get_full_package_version(d)))
>>      if modules:
>>          metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE')
>> -        d.appendVar('RDEPENDS_' + metapkg, ' '+' '.join(modules))
>> +        d.appendVar('RDEPENDS_' + metapkg, ' '+' '.join(['{0}
>> {1}'.format(module, get_full_package_version(d)) for module in modules]))
>>
>>      # If modules-load.d and modprobe.d are empty at this point, remove
>> them to
>>      # avoid warnings. removedirs only raises an OSError if an empty
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index 7a134d5c29..605c101e62 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -55,7 +55,7 @@ python __anonymous () {
>>
>>          d.setVar('FILES_kernel-image-' + typelower, '/' + imagedest +
>> '/' + type + '-${KERNEL_VERSION_NAME}')
>>
>> -        d.appendVar('RDEPENDS_kernel-image', ' ' + 'kernel-image-' +
>> typelower)
>> +        d.appendVar('RDEPENDS_kernel-image', ' ' + 'kernel-image-' +
>> typelower + ' ${@get_full_package_version(d)}')
>>
>>          d.setVar('PKG_kernel-image-' + typelower, 'kernel-image-' +
>> typelower + '-${KERNEL_VERSION_PKG_NAME}')
>>
>> @@ -493,14 +493,17 @@ FILES_kernel-image = ""
>>  FILES_kernel-dev = "/boot/System.map* /boot/Module.symvers*
>> /boot/config* ${KERNEL_SRC_PATH} ${nonarch_base_libdir}/modules
>> /${KERNEL_VERSION}/build"
>>  FILES_kernel-vmlinux = "/boot/vmlinux-${KERNEL_VERSION_NAME}"
>>  FILES_kernel-modules = ""
>> -RDEPENDS_kernel = "kernel-base"
>> +RDEPENDS_kernel = "kernel-base ${@get_full_package_version(d)}"
>>
>
> Is that really supposed to be a space, between kernel-base and the package
> version
> call ? I guess so, since I see the same thing below in the
> RDEPENDS_kernel-base
> line below .. but it just reads strange to me.  i.e. if that's a RDEPENDS,
> where is the
> package get_full_package_version(d) created ?
>
> Yes, the space is supposed to be there. If it's inconvenient here, it can
> be moved in the string returned by get_full_package_version()
>
> Are you trying to set a generic versionless RDEPENDS and a versioned one
> that doesn't
> contain 'kernel-' in the name ?
>
>
> This will create a versioned RDEPENDS. The syntax for a versioned package
> is: "package_name (= package_version)". This only append the version to the
> current value.
>

right. I was thinking of package rdepends, but not from the point of view
of a
package manager.

I think it would be better to get it all from the utility function, since
that makes it
clear that it is a constructed value of the form you mentioned.

Also, what if someone doesn't want the versioned depends ? If everything is
in a
routine, they could override to get the behaviour they want.

Out of curiosity .. have you tested this with both rpm and ipk ? I've run
into problems
with versioned depends and ipk in the past, so it would be good to confirm
that this
works consistently.


>
>  # Allow machines to override this dependency if kernel image files are
>>  # not wanted in images as standard
>> -RDEPENDS_kernel-base ?= "kernel-image"
>> -PKG_kernel-image = "kernel-image-${@legitimize_pa
>> ckage_name('${KERNEL_VERSION}')}"
>> +RDEPENDS_kernel-base ?= "kernel-image ${@get_full_package_version(d)}"
>> +PKG_kernel-image = "kernel-image-${KERNEL_VERSION_PKG_NAME}"
>>  RDEPENDS_kernel-image += "${@base_conditional('KERNEL_IMAGETYPE',
>> 'vmlinux', 'kernel-vmlinux', '', d)}"
>> -PKG_kernel-base = "kernel-${@legitimize_package_
>> name('${KERNEL_VERSION}')}"
>> -RPROVIDES_kernel-base += "kernel-${KERNEL_VERSION}"
>> +PKG_kernel-base = "kernel-${KERNEL_VERSION_PKG_NAME}"
>> +RPROVIDES_kernel-base += "kernel-${KERNEL_VERSION_PKG_NAME}"
>> +PKG_kernel-vmlinux = "kernel-vmlinux-${KERNEL_VERSION_PKG_NAME}"
>>
> +PKG_kernel-modules = "kernel-modules-${KERNEL_VERSION_PKG_NAME}"
>> +PKG_kernel-dev = "kernel-dev-${KERNEL_VERSION_PKG_NAME}"
>>  ALLOW_EMPTY_kernel = "1"
>>  ALLOW_EMPTY_kernel-base = "1"
>>  ALLOW_EMPTY_kernel-image = "1"
>> diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
>> b/meta/recipes-kernel/linux/linux-yocto.inc
>> index 637506a2a8..c3d1284ad2 100644
>> --- a/meta/recipes-kernel/linux/linux-yocto.inc
>> +++ b/meta/recipes-kernel/linux/linux-yocto.inc
>> @@ -67,3 +67,7 @@ do_install_append(){
>>  addtask kernel_version_sanity_check after do_kernel_metadata
>> do_kernel_checkout before do_compile
>>  addtask validate_branches before do_patch after do_kernel_checkout
>>  addtask kernel_configcheck after do_configure before do_compile
>> +
>> +def get_full_package_version(d):
>> +    return "(= " + d.getVar("PKGV") + "-" + d.getVar("PKGR") + ")"
>>
>
> This doesn't belong in linux-yocto.inc, since it is called in
> kernel.bbclass. It needs to be in the base
> class and have a namespace that indicates it is specific to the kernel.
>
> Yeah, you're right, this shouldn't be in linux-yocto.inc. I will move it
> to the base class, but I need some info about namespace thing, because I
> don't recall reading about it in documentations.
>

Nothing fancy here, more convention than something technical. If this is
only working for
the kernel, it should be def kernel_get_full_package_version() so the
context is clear and
if another class/package add something similar, we won't collide.

Bruce


>
> Bruce
>
>
>> +
>> --
>> 2.13.1
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end"
>
>
> --
>
> Razvan
>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 15939 bytes --]

Re: [PATCH 1/2] kernel: add package version in dependencies for kernel packages

[Razvan Heghedus]

[-- Attachment #1: Type: text/plain, Size: 10850 bytes --]



On 06/28/2017 04:10 AM, Bruce Ashfield wrote:
>
>
> On Tue, Jun 27, 2017 at 4:51 AM, Razvan Heghedus 
> <razvan.heghedus@ni.com <mailto:razvan.heghedus@ni.com>> wrote:
>
>
>
>     On 06/26/2017 06:50 PM, Bruce Ashfield wrote:
>>
>>
>>     On Wed, Jun 21, 2017 at 8:00 AM, Heghedus Razvan
>>     <razvan.heghedus@ni.com <mailto:razvan.heghedus@ni.com>> wrote:
>>
>>         Make all dependencies from kernel family packages which depend
>>         on another kernel related package to depend on the same version.
>>         This creates a consistent state where kernel, kernel images and
>>         kernel modules have the same version, making a kernel upgrade
>>         leading to upgrades of the image and modules.
>>
>>         The upgrade works only if the KERNEL_VERSION_PKG_NAME remains
>>         the same for the newer versions.
>>
>>         Signed-off-by: Heghedus Razvan <razvan.heghedus@ni.com
>>         <mailto:razvan.heghedus@ni.com>>
>>         ---
>>          meta/classes/kernel-module-split.bbclass |  7 ++++---
>>          meta/classes/kernel.bbclass  | 15 +++++++++------
>>          meta/recipes-kernel/linux/linux-yocto.inc |  4 ++++
>>          3 files changed, 17 insertions(+), 9 deletions(-)
>>
>>         diff --git a/meta/classes/kernel-module-split.bbclass
>>         b/meta/classes/kernel-module-split.bbclass
>>         index 5e10dcf735..e247e66901 100644
>>         --- a/meta/classes/kernel-module-split.bbclass
>>         +++ b/meta/classes/kernel-module-split.bbclass
>>         @@ -33,7 +33,7 @@ PACKAGESPLITFUNCS_prepend =
>>         "split_kernel_module_packages "
>>          KERNEL_MODULES_META_PACKAGE ?= "kernel-modules"
>>
>>          KERNEL_MODULE_PACKAGE_PREFIX ?= ""
>>         -KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
>>         +KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION_PKG_NAME}"
>>          KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1"
>>
>>          python split_kernel_module_packages () {
>>         @@ -114,6 +114,7 @@ python split_kernel_module_packages () {
>>                      for dep in vals["depends"].split(","):
>>                          on = legitimize_package_name(dep)
>>                          dependency_pkg = format % on
>>         +                dependency_pkg += '
>>         ${@get_full_package_version(d)}'
>>          modinfo_deps.append(dependency_pkg)
>>                  for dep in modinfo_deps:
>>                      if not dep in rdepends:
>>         @@ -138,10 +139,10 @@ python split_kernel_module_packages () {
>>              postinst = d.getVar('pkg_postinst_modules')
>>              postrm = d.getVar('pkg_postrm_modules')
>>
>>         -    modules = do_split_packages(d,
>>         root='${nonarch_base_libdir}/modules',
>>         file_regex=module_regex, output_pattern=module_pattern,
>>         description='%s kernel module', postinst=postinst,
>>         postrm=postrm, recursive=True, hook=frob_metadata,
>>         extra_depends='kernel-%s' % (d.getVar("KERNEL_VERSION")))
>>         +    modules = do_split_packages(d,
>>         root='${nonarch_base_libdir}/modules',
>>         file_regex=module_regex, output_pattern=module_pattern,
>>         description='%s kernel module', postinst=postinst,
>>         postrm=postrm, recursive=True, hook=frob_metadata,
>>         extra_depends='kernel-%s %s' %
>>         (d.getVar("KERNEL_VERSION_PKG_NAME"),
>>         get_full_package_version(d)))
>>              if modules:
>>                  metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE')
>>         -        d.appendVar('RDEPENDS_' + metapkg, ' '+'
>>         '.join(modules))
>>         +        d.appendVar('RDEPENDS_' + metapkg, ' '+'
>>         '.join(['{0} {1}'.format(module, get_full_package_version(d))
>>         for module in modules]))
>>
>>              # If modules-load.d and modprobe.d are empty at this
>>         point, remove them to
>>              # avoid warnings. removedirs only raises an OSError if
>>         an empty
>>         diff --git a/meta/classes/kernel.bbclass
>>         b/meta/classes/kernel.bbclass
>>         index 7a134d5c29..605c101e62 100644
>>         --- a/meta/classes/kernel.bbclass
>>         +++ b/meta/classes/kernel.bbclass
>>         @@ -55,7 +55,7 @@ python __anonymous () {
>>
>>                  d.setVar('FILES_kernel-image-' + typelower, '/' +
>>         imagedest + '/' + type + '-${KERNEL_VERSION_NAME}')
>>
>>         -        d.appendVar('RDEPENDS_kernel-image', ' ' +
>>         'kernel-image-' + typelower)
>>         +        d.appendVar('RDEPENDS_kernel-image', ' ' +
>>         'kernel-image-' + typelower + ' ${@get_full_package_version(d)}')
>>
>>                  d.setVar('PKG_kernel-image-' + typelower,
>>         'kernel-image-' + typelower + '-${KERNEL_VERSION_PKG_NAME}')
>>
>>         @@ -493,14 +493,17 @@ FILES_kernel-image = ""
>>          FILES_kernel-dev = "/boot/System.map* /boot/Module.symvers*
>>         /boot/config* ${KERNEL_SRC_PATH}
>>         ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
>>          FILES_kernel-vmlinux = "/boot/vmlinux-${KERNEL_VERSION_NAME}"
>>          FILES_kernel-modules = ""
>>         -RDEPENDS_kernel = "kernel-base"
>>         +RDEPENDS_kernel = "kernel-base ${@get_full_package_version(d)}"
>>
>>
>>     Is that really supposed to be a space, between kernel-base and
>>     the package version
>>     call ? I guess so, since I see the same thing below in the
>>     RDEPENDS_kernel-base
>>     line below .. but it just reads strange to me.  i.e. if that's a
>>     RDEPENDS, where is the
>>     package get_full_package_version(d) created ?
>>
>     Yes, the space is supposed to be there. If it's inconvenient here,
>     it can be moved in the string returned by get_full_package_version()
>>     Are you trying to set a generic versionless RDEPENDS and a
>>     versioned one that doesn't
>>     contain 'kernel-' in the name ?
>     This will create a versioned RDEPENDS. The syntax for a versioned
>     package is: "package_name (= package_version)". This only append
>     the version to the current value.
>
>
> right. I was thinking of package rdepends, but not from the point of 
> view of a
> package manager.
>
> I think it would be better to get it all from the utility function, 
> since that makes it
> clear that it is a constructed value of the form you mentioned.
>
> Also, what if someone doesn't want the versioned depends ? If 
> everything is in a
> routine, they could override to get the behaviour they want.
There isn't a way to disable the versioned depends. Theoretically there 
shouldn't be problems, because this enforce that the modules and the 
kernel are at the same version(I mean the kernel and it's modules needs 
to be at the same version, so I don't see any problem with this). I 
could add a conditionals everywhere, but that involves an another variable.
>
> Out of curiosity .. have you tested this with both rpm and ipk ? I've 
> run into problems
> with versioned depends and ipk in the past, so it would be good to 
> confirm that this
> works consistently.
I tested with all package types(deb, rmp and ipk) and I didn't have any 
problem at all.
>
>
>>          # Allow machines to override this dependency if kernel image
>>         files are
>>          # not wanted in images as standard
>>         -RDEPENDS_kernel-base ?= "kernel-image"
>>         -PKG_kernel-image =
>>         "kernel-image-${@legitimize_package_name('${KERNEL_VERSION}')}"
>>         +RDEPENDS_kernel-base ?= "kernel-image
>>         ${@get_full_package_version(d)}"
>>         +PKG_kernel-image = "kernel-image-${KERNEL_VERSION_PKG_NAME}"
>>          RDEPENDS_kernel-image +=
>>         "${@base_conditional('KERNEL_IMAGETYPE', 'vmlinux',
>>         'kernel-vmlinux', '', d)}"
>>         -PKG_kernel-base =
>>         "kernel-${@legitimize_package_name('${KERNEL_VERSION}')}"
>>         -RPROVIDES_kernel-base += "kernel-${KERNEL_VERSION}"
>>         +PKG_kernel-base = "kernel-${KERNEL_VERSION_PKG_NAME}"
>>         +RPROVIDES_kernel-base += "kernel-${KERNEL_VERSION_PKG_NAME}"
>>         +PKG_kernel-vmlinux = "kernel-vmlinux-${KERNEL_VERSION_PKG_NAME}"
>>
>>         +PKG_kernel-modules = "kernel-modules-${KERNEL_VERSION_PKG_NAME}"
>>         +PKG_kernel-dev = "kernel-dev-${KERNEL_VERSION_PKG_NAME}"
>>          ALLOW_EMPTY_kernel = "1"
>>          ALLOW_EMPTY_kernel-base = "1"
>>          ALLOW_EMPTY_kernel-image = "1"
>>         diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
>>         b/meta/recipes-kernel/linux/linux-yocto.inc
>>         index 637506a2a8..c3d1284ad2 100644
>>         --- a/meta/recipes-kernel/linux/linux-yocto.inc
>>         +++ b/meta/recipes-kernel/linux/linux-yocto.inc
>>         @@ -67,3 +67,7 @@ do_install_append(){
>>          addtask kernel_version_sanity_check after do_kernel_metadata
>>         do_kernel_checkout before do_compile
>>          addtask validate_branches before do_patch after
>>         do_kernel_checkout
>>          addtask kernel_configcheck after do_configure before do_compile
>>         +
>>         +def get_full_package_version(d):
>>         +    return "(= " + d.getVar("PKGV") + "-" + d.getVar("PKGR")
>>         + ")"
>>
>>
>>     This doesn't belong in linux-yocto.inc, since it is called in
>>     kernel.bbclass. It needs to be in the base
>>     class and have a namespace that indicates it is specific to the
>>     kernel.
>>
>     Yeah, you're right, this shouldn't be in linux-yocto.inc. I will
>     move it to the base class, but I need some info about namespace
>     thing, because I don't recall reading about it in documentations.
>
>
> Nothing fancy here, more convention than something technical. If this 
> is only working for
> the kernel, it should be def kernel_get_full_package_version() so the 
> context is clear and
> if another class/package add something similar, we won't collide.
>
> Bruce
>
>
>>     Bruce
>>
>>         +
>>         --
>>         2.13.1
>>
>>         --
>>         _______________________________________________
>>         Openembedded-core mailing list
>>         Openembedded-core@lists.openembedded.org
>>         <mailto:Openembedded-core@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"
>
>     -- 
>
>     Razvan
>
>
>
>
> -- 
> "Thou shalt not follow the NULL pointer, for chaos and madness await 
> thee at its end"

-- 

Razvan


[-- Attachment #2: Type: text/html, Size: 23865 bytes --]

Re: [PATCH 1/2] kernel: add package version in dependencies for kernel packages

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 9831 bytes --]

On Thu, Jun 29, 2017 at 4:54 AM, Razvan Heghedus <razvan.heghedus@ni.com>
wrote:

>
>
> On 06/28/2017 04:10 AM, Bruce Ashfield wrote:
>
>
>
> On Tue, Jun 27, 2017 at 4:51 AM, Razvan Heghedus <razvan.heghedus@ni.com>
> wrote:
>
>>
>>
>> On 06/26/2017 06:50 PM, Bruce Ashfield wrote:
>>
>>
>>
>> On Wed, Jun 21, 2017 at 8:00 AM, Heghedus Razvan <razvan.heghedus@ni.com>
>> wrote:
>>
>>> Make all dependencies from kernel family packages which depend
>>> on another kernel related package to depend on the same version.
>>> This creates a consistent state where kernel, kernel images and
>>> kernel modules have the same version, making a kernel upgrade
>>> leading to upgrades of the image and modules.
>>>
>>> The upgrade works only if the KERNEL_VERSION_PKG_NAME remains
>>> the same for the newer versions.
>>>
>>> Signed-off-by: Heghedus Razvan <razvan.heghedus@ni.com>
>>> ---
>>>  meta/classes/kernel-module-split.bbclass  |  7 ++++---
>>>  meta/classes/kernel.bbclass               | 15 +++++++++------
>>>  meta/recipes-kernel/linux/linux-yocto.inc |  4 ++++
>>>  3 files changed, 17 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/meta/classes/kernel-module-split.bbclass
>>> b/meta/classes/kernel-module-split.bbclass
>>> index 5e10dcf735..e247e66901 100644
>>> --- a/meta/classes/kernel-module-split.bbclass
>>> +++ b/meta/classes/kernel-module-split.bbclass
>>> @@ -33,7 +33,7 @@ PACKAGESPLITFUNCS_prepend =
>>> "split_kernel_module_packages "
>>>  KERNEL_MODULES_META_PACKAGE ?= "kernel-modules"
>>>
>>>  KERNEL_MODULE_PACKAGE_PREFIX ?= ""
>>> -KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
>>> +KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION_PKG_NAME}"
>>>  KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1"
>>>
>>>  python split_kernel_module_packages () {
>>> @@ -114,6 +114,7 @@ python split_kernel_module_packages () {
>>>              for dep in vals["depends"].split(","):
>>>                  on = legitimize_package_name(dep)
>>>                  dependency_pkg = format % on
>>> +                dependency_pkg += ' ${@get_full_package_version(d)}'
>>>                  modinfo_deps.append(dependency_pkg)
>>>          for dep in modinfo_deps:
>>>              if not dep in rdepends:
>>> @@ -138,10 +139,10 @@ python split_kernel_module_packages () {
>>>      postinst = d.getVar('pkg_postinst_modules')
>>>      postrm = d.getVar('pkg_postrm_modules')
>>>
>>> -    modules = do_split_packages(d, root='${nonarch_base_libdir}/modules',
>>> file_regex=module_regex, output_pattern=module_pattern, description='%s
>>> kernel module', postinst=postinst, postrm=postrm, recursive=True,
>>> hook=frob_metadata, extra_depends='kernel-%s' %
>>> (d.getVar("KERNEL_VERSION")))
>>> +    modules = do_split_packages(d, root='${nonarch_base_libdir}/modules',
>>> file_regex=module_regex, output_pattern=module_pattern, description='%s
>>> kernel module', postinst=postinst, postrm=postrm, recursive=True,
>>> hook=frob_metadata, extra_depends='kernel-%s %s' %
>>> (d.getVar("KERNEL_VERSION_PKG_NAME"), get_full_package_version(d)))
>>>      if modules:
>>>          metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE')
>>> -        d.appendVar('RDEPENDS_' + metapkg, ' '+' '.join(modules))
>>> +        d.appendVar('RDEPENDS_' + metapkg, ' '+' '.join(['{0}
>>> {1}'.format(module, get_full_package_version(d)) for module in modules]))
>>>
>>>      # If modules-load.d and modprobe.d are empty at this point, remove
>>> them to
>>>      # avoid warnings. removedirs only raises an OSError if an empty
>>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>>> index 7a134d5c29..605c101e62 100644
>>> --- a/meta/classes/kernel.bbclass
>>> +++ b/meta/classes/kernel.bbclass
>>> @@ -55,7 +55,7 @@ python __anonymous () {
>>>
>>>          d.setVar('FILES_kernel-image-' + typelower, '/' + imagedest +
>>> '/' + type + '-${KERNEL_VERSION_NAME}')
>>>
>>> -        d.appendVar('RDEPENDS_kernel-image', ' ' + 'kernel-image-' +
>>> typelower)
>>> +        d.appendVar('RDEPENDS_kernel-image', ' ' + 'kernel-image-' +
>>> typelower + ' ${@get_full_package_version(d)}')
>>>
>>>          d.setVar('PKG_kernel-image-' + typelower, 'kernel-image-' +
>>> typelower + '-${KERNEL_VERSION_PKG_NAME}')
>>>
>>> @@ -493,14 +493,17 @@ FILES_kernel-image = ""
>>>  FILES_kernel-dev = "/boot/System.map* /boot/Module.symvers*
>>> /boot/config* ${KERNEL_SRC_PATH} ${nonarch_base_libdir}/modules
>>> /${KERNEL_VERSION}/build"
>>>  FILES_kernel-vmlinux = "/boot/vmlinux-${KERNEL_VERSION_NAME}"
>>>  FILES_kernel-modules = ""
>>> -RDEPENDS_kernel = "kernel-base"
>>> +RDEPENDS_kernel = "kernel-base ${@get_full_package_version(d)}"
>>>
>>
>> Is that really supposed to be a space, between kernel-base and the
>> package version
>> call ? I guess so, since I see the same thing below in the
>> RDEPENDS_kernel-base
>> line below .. but it just reads strange to me.  i.e. if that's a
>> RDEPENDS, where is the
>> package get_full_package_version(d) created ?
>>
>> Yes, the space is supposed to be there. If it's inconvenient here, it can
>> be moved in the string returned by get_full_package_version()
>>
>> Are you trying to set a generic versionless RDEPENDS and a versioned one
>> that doesn't
>> contain 'kernel-' in the name ?
>>
>>
>> This will create a versioned RDEPENDS. The syntax for a versioned package
>> is: "package_name (= package_version)". This only append the version to the
>> current value.
>>
>
> right. I was thinking of package rdepends, but not from the point of view
> of a
> package manager.
>
> I think it would be better to get it all from the utility function, since
> that makes it
> clear that it is a constructed value of the form you mentioned.
>
> Also, what if someone doesn't want the versioned depends ? If everything
> is in a
> routine, they could override to get the behaviour they want.
>
> There isn't a way to disable the versioned depends. Theoretically there
> shouldn't be problems, because this enforce that the modules and the kernel
> are at the same version(I mean the kernel and it's modules needs to be at
> the same version, so I don't see any problem with this). I could add a
> conditionals everywhere, but that involves an another variable.
>
>
> Out of curiosity .. have you tested this with both rpm and ipk ? I've run
> into problems
> with versioned depends and ipk in the past, so it would be good to confirm
> that this
> works consistently.
>
> I tested with all package types(deb, rmp and ipk) and I didn't have any
> problem at all.
>

That's good news!

Bruce


>
>
>
>>
>>  # Allow machines to override this dependency if kernel image files are
>>>  # not wanted in images as standard
>>> -RDEPENDS_kernel-base ?= "kernel-image"
>>> -PKG_kernel-image = "kernel-image-${@legitimize_pa
>>> ckage_name('${KERNEL_VERSION}')}"
>>> +RDEPENDS_kernel-base ?= "kernel-image ${@get_full_package_version(d)}"
>>> +PKG_kernel-image = "kernel-image-${KERNEL_VERSION_PKG_NAME}"
>>>  RDEPENDS_kernel-image += "${@base_conditional('KERNEL_IMAGETYPE',
>>> 'vmlinux', 'kernel-vmlinux', '', d)}"
>>> -PKG_kernel-base = "kernel-${@legitimize_package_
>>> name('${KERNEL_VERSION}')}"
>>> -RPROVIDES_kernel-base += "kernel-${KERNEL_VERSION}"
>>> +PKG_kernel-base = "kernel-${KERNEL_VERSION_PKG_NAME}"
>>> +RPROVIDES_kernel-base += "kernel-${KERNEL_VERSION_PKG_NAME}"
>>> +PKG_kernel-vmlinux = "kernel-vmlinux-${KERNEL_VERSION_PKG_NAME}"
>>>
>> +PKG_kernel-modules = "kernel-modules-${KERNEL_VERSION_PKG_NAME}"
>>> +PKG_kernel-dev = "kernel-dev-${KERNEL_VERSION_PKG_NAME}"
>>>  ALLOW_EMPTY_kernel = "1"
>>>  ALLOW_EMPTY_kernel-base = "1"
>>>  ALLOW_EMPTY_kernel-image = "1"
>>> diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
>>> b/meta/recipes-kernel/linux/linux-yocto.inc
>>> index 637506a2a8..c3d1284ad2 100644
>>> --- a/meta/recipes-kernel/linux/linux-yocto.inc
>>> +++ b/meta/recipes-kernel/linux/linux-yocto.inc
>>> @@ -67,3 +67,7 @@ do_install_append(){
>>>  addtask kernel_version_sanity_check after do_kernel_metadata
>>> do_kernel_checkout before do_compile
>>>  addtask validate_branches before do_patch after do_kernel_checkout
>>>  addtask kernel_configcheck after do_configure before do_compile
>>> +
>>> +def get_full_package_version(d):
>>> +    return "(= " + d.getVar("PKGV") + "-" + d.getVar("PKGR") + ")"
>>>
>>
>> This doesn't belong in linux-yocto.inc, since it is called in
>> kernel.bbclass. It needs to be in the base
>> class and have a namespace that indicates it is specific to the kernel.
>>
>> Yeah, you're right, this shouldn't be in linux-yocto.inc. I will move it
>> to the base class, but I need some info about namespace thing, because I
>> don't recall reading about it in documentations.
>>
>
> Nothing fancy here, more convention than something technical. If this is
> only working for
> the kernel, it should be def kernel_get_full_package_version() so the
> context is clear and
> if another class/package add something similar, we won't collide.
>
> Bruce
>
>
>>
>> Bruce
>>
>>
>>> +
>>> --
>>> 2.13.1
>>>
>>> --
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee
>> at its end"
>>
>>
>> --
>>
>> Razvan
>>
>>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end"
>
>
> --
>
> Razvan
>
>


-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 24446 bytes --]

[PATCH 2/2] kernel: user defined KERNEL_VERSION_PKG_NAME

[Heghedus Razvan]

Add possibility to set KERNEL_VERSION_PKG_NAME to a user
defined value.

Signed-off-by: Heghedus Razvan <razvan.heghedus@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 ""}"
 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'))}")
+
     # 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