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