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.heghe...@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.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>
>> 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
>>> > wrote:
>>>
>>>> Add possibility to set KERNEL_VERSION_PKG_NAME to a user
>>>> defined value.
>>>>
>>>> Signed-off-by: Heghedus Razvan <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 "
>>>> <$%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"
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
