<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>I've tried to find some e-mail threads about it, part of that discussion is in:</div><div><a href="https://patchwork.openembedded.org/patch/37461/">https://patchwork.openembedded.org/patch/37461/</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 13, 2017 at 11:34 AM, André Draszik <span dir="ltr"><<a href="mailto:git@andred.net" target="_blank">git@andred.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Only during do_rootfs indeed (I don't ever do upgrades on the target using<br>
opkg).<br>
<br>
Is there a reason to still specify prefer-arch-to-version? I'd actually<br>
expect the exact opposite compared to the original commit message's<br>
statement, unless the version numbers are identical.<br>
<br>
Also, I would argue that the defaults during do_rootfs and when using opkg<br>
on the target should be the same...<br>
<br>
Cheers,<br>
Andre'<br>
<br>
<br>
On Mon, 2017-11-13 at 11:12 +0100, Martin Jansa wrote:<br>
> Is this during do_rootfs or are you seeing this issue when upgrading on<br>
> the<br>
> target as well?<br>
><br>
> I haven't found the bug for this but IIRC it's because do_rootfs is using<br>
> --prefer-arch-to-version parameter.<br>
> meta/classes/package_ipk.<wbr>bbclass:OPKG_ARGS += "--force_postinstall<br>
> --prefer-arch-to-version"<br>
> which causes this undesired behavior.<br>
><br>
> On Mon, Nov 13, 2017 at 9:54 AM, André Draszik <<a href="mailto:git@andred.net">git@andred.net</a>> wrote:<br>
><br>
> > Hi,<br>
> ><br>
> > On Mon, 2017-11-13 at 13:26 +0800, Chen Qi wrote:<br>
> > > autoconf-archive is a set of common m4 macros, it should be allarch,<br>
> > > just like it is on other distros.<br>
> ><br>
> > I have found previously that when changing a recipe to produce more<br>
> > generic<br>
> > output, like in this case, and the old binary package is still in<br>
> > deploy/,<br>
> > then the package manager would always pick the more specific version,<br>
> > even<br>
> > if a more recent (by package version) exists in deploy. In my case I was<br>
> > moving from PACKAGE_ARCH=${MACHINE_ARCH} to<br>
> > PACKAGE_ARCH=${TUNE_PKGARCH},<br>
> > but I guess it'll be the same here.<br>
> ><br>
> > What is the correct way to deal with that other that cleansstate?<br>
> ><br>
> > Cheers,<br>
> > Andre'<br>
> ><br>
> > --<br>
> > ______________________________<wbr>_________________<br>
> > Openembedded-core mailing list<br>
> > <a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.<wbr>openembedded.org</a><br>
> > <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>core</a><br>
> ><br>
</blockquote></div><br></div>