From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f67.google.com (mail-lf0-f67.google.com [209.85.215.67]) by mail.openembedded.org (Postfix) with ESMTP id 20C2877F90 for ; Thu, 29 Jun 2017 13:06:50 +0000 (UTC) Received: by mail-lf0-f67.google.com with SMTP id g21so7658828lfk.1 for ; Thu, 29 Jun 2017 06:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+yEtoc0ulcKxPREAO0jlxDOE6dDUAZBsscNx9y3jkUA=; b=mH+tZUSXcWzzOqIqBGMgo37Wfj3/xsPvBWy+HadgpK10Nlb9apbu8AzOGeeSsg73AS GgM4uiwdhLuqbvMGMzXoZ0nXJMyb2a5h9mefiuLamzd4byR8EE9ki2N/xR5pYchdLTRq MkPAR24T1jDc4K2dIA0rx1FGG1Ub33HGT/uJ5y8pdDhdN3u2+p5Th/WkwT3SVdELaUAh EcDdBDrSvtk1Upyt3lNp2msHnUF2pjvbYx3F0JOgJnljPlzP1SeccslMyys6GeeGXNI/ MExB7tlF4qC8GaFgiC4IbrzIXogowH9h3LwEtUElqcKZ35ZhTqjivJewARPiSf5mk1j9 2upQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+yEtoc0ulcKxPREAO0jlxDOE6dDUAZBsscNx9y3jkUA=; b=DG09DNQ40RU2lKeogTMvjADJR6m7k5J1ZTtv2QNdFW3UlJqWIW+wF2ddgVwMCsWyMl 2GGqzJFfU4U/RW7IT/GNcBmUF1iX2ajyBsISFL/op21teyGAFqbUqCUVuB6BHsTtxn7D OSu8dwZ3PPUfBc+xgPc4YAmGfMTm3NHCWBGzrOPzOtQ1pdaRlrLIb8qZJedu7HM8vPUO 1xMaTPg2lSUoKATairBSzvPo0bQctJn7JjXhOvbcPjsLZ3M6ISugNSqkJWYnhpcBuMQ1 iWtFRcSQARkY0K01tHiiw8piqgGCeBkUlJaBCoAQJPXCrAx32cediWb1++ndd53kC5rd cvEg== X-Gm-Message-State: AKS2vOywzvtSGEeiJ1i7c9/5mjnBoI4330fBMO8mmHggJYIw7xifcd1Y lfSnLttxxic6bQw2kqHlg7R1zg9BRQ== X-Received: by 10.25.72.145 with SMTP id v139mr4711142lfa.18.1498741611351; Thu, 29 Jun 2017 06:06:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.9.137 with HTTP; Thu, 29 Jun 2017 06:06:50 -0700 (PDT) In-Reply-To: <23f339ea-47ed-7a93-5583-a74b555c690c@ni.com> References: <20170621120003.6440-1-razvan.heghedus@ni.com> <20170621120003.6440-2-razvan.heghedus@ni.com> <945a7f98-d3f7-7d41-c440-0bd71bb4ee19@ni.com> <23f339ea-47ed-7a93-5583-a74b555c690c@ni.com> From: Bruce Ashfield Date: Thu, 29 Jun 2017 09:06:50 -0400 Message-ID: To: Razvan Heghedus Cc: Patches and discussions about the oe-core layer Subject: Re: [PATCH 2/2] kernel: user defined KERNEL_VERSION_PKG_NAME X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 13:06:51 -0000 Content-Type: multipart/alternative; boundary="94eb2c0d00085ad399055318f9c8" --94eb2c0d00085ad399055318f9c8 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 29, 2017 at 5:10 AM, Razvan Heghedus wrote: > > > On 06/28/2017 04:29 AM, Bruce Ashfield wrote: > > > > On Tue, Jun 27, 2017 at 5:15 AM, Razvan Heghedus > wrote: > >> >> >> On 06/26/2017 06:52 PM, Bruce Ashfield wrote: >> >> >> >> On Wed, Jun 21, 2017 at 8:00 AM, Heghedus Razvan >> wrote: >> >>> Add possibility to set KERNEL_VERSION_PKG_NAME to a user >>> defined value. >>> >>> Signed-off-by: Heghedus Razvan >>> --- >>> 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" --94eb2c0d00085ad399055318f9c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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



On 06/28/2017 04:29 AM, Bruce Ashfield wrote:
=20


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 &= lt;razvan.heghe= dus@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>
---
=C2=A0meta/classes/kernel.bbclass | 8 ++++++-= -
=C2=A01 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 ?=3D ""
=C2=A0# LINUX_VERSION which is a constant. =C2=A0KERNEL_VERSION_NAME =3D "${@d.getVar('KERNEL_VERSION') or ""}"
=C2=A0KERNEL_VERSION_NAME[vardepvalue] = =3D "${LINUX_VERSION}"
-KERNEL_VERSION_PKG_NAME =3D "${@legitimize_package_name(d.getVa= r('KERNEL_VERSION'))}"
-KERNEL_VERSION_PKG_NAME[vardepvalue] =3D "${LINUX_VERSION}"

=C2=A0python __anonymous () {
=C2=A0 =C2=A0 =C2=A0import re

+=C2=A0 =C2=A0 if d.getVar('USER_KERNEL_V= ERSION_PKG') is None :
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 d.setVar('KE= RNEL_VERSION_PKG_NAME', "${@legitimize_package_name(d.getVa= r('KERNEL_VERSION'))}")
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 d.setVar('KE= RNEL_VERSION_PKG_NAME[vardepvalue]', "${LINUX_VERSION}")
+=C2=A0 =C2=A0 else:
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 d.setVar('KE= RNEL_VERSION_PKG_NAME', "${@legitimize_package_name(d.getVa= r('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 extr= a
variables.

Bruce
=C2=A0
+
=C2=A0 =C2=A0 =C2=A0# Merge KERNEL_IMAGETYPE = and KERNEL_ALT_IMAGETYPE into KERNEL_IMAGETYPES
=C2=A0 =C2=A0 =C2=A0type =3D d.getVar('KE= RNEL_IMAGETYPE') or ""
=C2=A0 =C2=A0 =C2=A0alttype =3D d.getVar('KERNEL_ALT_IMAGETYPE')= or ""
--
2.13.1

--
____________________________________= ___________
Openembedded-core mailing list
Openembedded-core@lists.openembed= ded.org
ht= tp://lists.openembedded.org/mailman/listinfo/openembedded-core



--
&= quot;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. =C2=A0i.e. the PV is already picked u= p 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+4d929fac= 34_d2c1ed3c0c-r0_qemux86_64.ipk
package, I see that it has:

=C2=A0Version: 4.10.15+git0+4d929fac34_d2c1ed3c0c-r0
=C2=A0but 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

=C2=A0
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 (=3D 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 (=3D 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 (=3D 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.



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 o= f the commercially supported distros do) .. unless
it has been in= advertently 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 hav= e documentation
updates along with it .. or we'll surely forg= et to document it and catch people by surprise :(

= Bruce
=C2=A0

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.
--=20

Razvan



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

--=20

Razvan



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