On 06/29/2017 04:06 PM, Bruce Ashfield wrote:
On Thu, Jun 29, 2017 at 5:10 AM, Razvan Heghedus
<razvan.heghe...@ni.com <mailto:razvan.heghe...@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.heghe...@ni.com <mailto:razvan.heghe...@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.heghe...@ni.com <mailto:razvan.heghe...@ni.com>> wrote:
Add possibility to set KERNEL_VERSION_PKG_NAME to a user
defined value.
Signed-off-by: Heghedus Razvan <razvan.heghe...@ni.com
<mailto:razvan.heghe...@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
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
