On Thu, Feb 16, 2017 at 5:43 AM, Bryan Evenson <beven...@melinkcorp.com> wrote:
>
> 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.
>
Ah yes if its in PN then PE wont help here you have to establish the
relationship between old and new PN, RCONFLICTS/RREPLACES is probably
the best bet
> Could someone explain to me why KERNEL_VERSION is even in the package name to
> begin with?
Perhaps so that you can have have multiple kernels installed in parallel.
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.
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
