Only during do_rootfs indeed (I don't ever do upgrades on the target using opkg).
Is there a reason to still specify prefer-arch-to-version? I'd actually expect the exact opposite compared to the original commit message's statement, unless the version numbers are identical. Also, I would argue that the defaults during do_rootfs and when using opkg on the target should be the same... Cheers, Andre' On Mon, 2017-11-13 at 11:12 +0100, Martin Jansa wrote: > Is this during do_rootfs or are you seeing this issue when upgrading on > the > target as well? > > I haven't found the bug for this but IIRC it's because do_rootfs is using > --prefer-arch-to-version parameter. > meta/classes/package_ipk.bbclass:OPKG_ARGS += "--force_postinstall > --prefer-arch-to-version" > which causes this undesired behavior. > > On Mon, Nov 13, 2017 at 9:54 AM, André Draszik <[email protected]> wrote: > > > Hi, > > > > On Mon, 2017-11-13 at 13:26 +0800, Chen Qi wrote: > > > autoconf-archive is a set of common m4 macros, it should be allarch, > > > just like it is on other distros. > > > > I have found previously that when changing a recipe to produce more > > generic > > output, like in this case, and the old binary package is still in > > deploy/, > > then the package manager would always pick the more specific version, > > even > > if a more recent (by package version) exists in deploy. In my case I was > > moving from PACKAGE_ARCH=${MACHINE_ARCH} to > > PACKAGE_ARCH=${TUNE_PKGARCH}, > > but I guess it'll be the same here. > > > > What is the correct way to deal with that other that cleansstate? > > > > Cheers, > > Andre' > > > > -- > > _______________________________________________ > > Openembedded-core mailing list > > [email protected] > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
