[OE-core] Suggested RREPLACES/RCONFLICTS for easier kernel-image upgrades

Fri Feb 17 15:13:29 UTC 2017

Andreas,

> -----Original Message-----
> From: openembedded-core-bounces at lists.openembedded.org
> [mailto:openembedded-core-bounces at lists.openembedded.org] On Behalf
> Of Andreas Oberritter
> Sent: Friday, February 17, 2017 5:46 AM
> To: openembedded-core at lists.openembedded.org
> Subject: Re: [OE-core] Suggested RREPLACES/RCONFLICTS for easier kernel-
> image upgrades
> 
> On Thu, 16 Feb 2017 13:43:03 +0000
> Bryan Evenson <bevenson at melinkcorp.com> wrote:
> 
> > Khem,
> >
> > > -----Original Message-----
> > > From: openembedded-core-bounces at lists.openembedded.org
> > > [mailto:openembedded-core-bounces at lists.openembedded.org] On
> Behalf
> > > Of Khem Raj
> > > Sent: Wednesday, February 15, 2017 5:17 PM
> > > To: openembedded-core at lists.openembedded.org
> > > Subject: Re: [OE-core] Suggested RREPLACES/RCONFLICTS for easier
> kernel-
> > > image upgrades
> > >
> > >
> > >
> > > On 2/15/17 1:54 PM, Bryan Evenson wrote:
> > > > For one project I'm using an Atmel AT91SAM9G25 processor, and I
> started
> > > when support for the chip wasn't fully integrated into the mainline
> kernel.
> > > As a result, I was using Atmel's Linux fork.  Support has been in the
> mainline
> > > kernel for a while now, so in the middle of doing other updates I plan on
> > > switching to using one of the mainline LTS releases.  I'm using the kernel
> > > recipe in the meta-sunxi layer as an example (located here:
> > > https://github.com/linux-sunxi/meta-sunxi/blob/master/recipes-
> > > kernel/linux/linux_4.4.40.bb). I also plan on keeping more up to date on
> > > releases.  However, due to the package naming for the kernel images,
> the
> > > RREPLACES/RCONFLICTS statements for firmware upgrade for this recipe
> is
> > > getting ridiculous.  I'm currently building for kernel version 4.1.38, and
> here's
> > > what I have so far to handle all previous cases:
> > > >
> > > > RREPLACES_kernel-image = "kernel-image (<= 4.1) kernel-image-3.6.9-
> > > yocto-standard kernel-image-3.10.0-yocto-standard kernel-image-3.10.0-
> > > at91"
> > > > RCONFLICTS_kernel-image = "kernel-image (<= 4.1) kernel-image-
> 3.6.9-
> > > yocto-standard kernel-image-3.10.0-yocto-standard kernel-image-3.10.0-
> > > at91"
> > > >
> > > > If it makes a difference, I'm using opkg for a package manager.  Since
> the
> > > kernel version is in the package name, I'm assuming that if I do keep
> going
> > > forward and relatively up to date with LTS release, I'll have to start adding
> > > "kernel-image-4.1.38 kernel-image-4.1.39 kernel-image 4.1.40 ...." to the
> > > RREPLACES/RCONFLICTS so opkg will upgrade the kernel.
> > > >
> > > > Is there a better way to do this?  I've tried using some wildcards in the
> > > package names without any success.
> > > >
> > >
> > > you can increment PE
> >
> > I tried that and it didn't make a difference; without the specific previous
> package names listed in RDEPENDS/RCONFLICTS, opkg does not recognize
> the new kernel-image as an upgrade.  From my understanding PE only
> affects the version number, not the package name.  In this case, since
> KERNEL_VERSION is part of the package name, opkg does not immediately
> recognize kernel-image-4.1.38 as an upgrade for kernel-image-3.10.0-at91.
> Even though both packages provide "kernel-image", that's not what opkg is
> looking at when it checks for upgrades.
> >
> > Could someone explain to me why KERNEL_VERSION is even in the
> package name to begin with?  I'm tempted to remove the following two lines
> from kernel.bbclass:
> >
> > PKG_kernel-image = "kernel-image-
> ${@legitimize_package_name('${KERNEL_VERSION}')}"
> > PKG_kernel-base = "kernel-
> ${@legitimize_package_name('${KERNEL_VERSION}')}"
> >
> > However, I don't know if this will break something else that would cause an
> even bigger problem.
> 
> That's what I do in my kernel recipes:
> 
> # By default, kernel.bbclass modifies package names to allow multiple
> kernels
> # to be installed in parallel. We revert this change and rprovide the versioned
> # package names instead, to allow only one kernel to be installed.
> PKG_kernel = "kernel"
> RPROVIDES_kernel = "kernel-${KERNEL_VERSION_PKG_NAME}"
> PKG_kernel-base = "kernel-base"
> RPROVIDES_kernel-base = "kernel-base-${KERNEL_VERSION_PKG_NAME}"
> RDEPENDS_kernel-base = ""
> PACKAGES_remove = "kernel-image"

I tried this approach but ran into problems during the build.  KERNEL_VERSION_PKG_NAME is not a variable that is set anywhere in my build.  Where is this set for you?  To test building I changed this to KERNEL_VERSION in my recipe.

I also have a package that depends on certain kernel versions (to handle when certain hardware interfaces have changed) which I previously had handled with this dependency:
RDEPENDS_${PN} = "kernel-image (<=3.10)"
Since after this change kernel-image no longer exists, I can't do this check.  What should this be instead?  "kernel" instead of "kernel-image"?  I did this and it built okay.  I also noticed that if I don't have this RDEPENDS in place, the kernel is not installed in my image.  Did you have to do something different to get the kernel package installed in your image in the first place?

I have a pkg_postinstall_kernel-image_append that writes the upgraded kernel to flash.   I'm assuming then I should change this to pkg_postinstall_kernel_append?  The uImage also wasn't getting attached to any file so I added:

FILES_kernel += "/boot/uImage-${KERNEL_VERSION}"

Is this what you did, or are there some other steps I'm missing?

Thanks,
Bryan

> 
> You may need to add some RCONFLICTS+RREPLACES for your old kernels, but
> the problem would be solved for future updates.
> 
> Note that a change landed in master recently which also places the kernel
> version in the name of every kernel module package. To avoid this, you
> need to set the following variables globally:
> 
> KERNEL_MODULE_PACKAGE_SUFFIX = ""
> KERNEL_MODULE_PROVIDE_VIRTUAL = "0"
> 
> Regards,
> Andreas
> 
> 
> >
> > Thanks,
> > Bryan
> >
> > >
> > > > Thanks,
> > > > Bryan
> > > >
> > > --
> > > _______________________________________________
> > > Openembedded-core mailing list
> > > Openembedded-core at lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core