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

> Thanks,
> Bryan
> 
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to