I don't remember the details, but IIRC it was libdrm or something like that for some MACHINE which was providing older version of libdrm with MACHINE_ARCH with better support for that MACHINE.
So this controversial patch was implemented for opkg to support that use-case and the default behavior was changed ignoring complains from me and Koen that this behavior is wrong. I've tried to find some e-mail threads about it, part of that discussion is in: https://patchwork.openembedded.org/patch/37461/ On Mon, Nov 13, 2017 at 11:34 AM, André Draszik <[email protected]> wrote: > 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
