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

Razvan Heghedus razvan.heghedus at ni.com
Thu Jun 29 08:54:37 UTC 2017



On 06/28/2017 04:10 AM, Bruce Ashfield wrote:
>
>
> On Tue, Jun 27, 2017 at 4:51 AM, Razvan Heghedus 
> <razvan.heghedus at ni.com <mailto:razvan.heghedus at 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 at ni.com <mailto:razvan.heghedus at 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 at ni.com
>>         <mailto:razvan.heghedus at 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 at lists.openembedded.org
>>         <mailto:Openembedded-core at lists.openembedded.org>
>>         http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>         <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
>>
>>
>>
>>
>>     -- 
>>     "Thou shalt not follow the NULL pointer, for chaos and madness
>>     await thee at its end"
>
>     -- 
>
>     Razvan
>
>
>
>
> -- 
> "Thou shalt not follow the NULL pointer, for chaos and madness await 
> thee at its end"

-- 

Razvan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170629/4f0acdc1/attachment-0002.html>


More information about the Openembedded-core mailing list