But don't we remove the old version from the feeds, or does that only happen if the arch matches?
Ross On 14 November 2017 at 10:16, André Draszik <[email protected]> wrote: > On Mon, 2017-11-13 at 19:54 +0800, Robert Yang wrote: > > > > On 11/13/2017 04:54 PM, André Draszik 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. > > > > I think that it is because of the priority MACHINE_ARCH > TUNE_PKGARCH > > > allarch, > > which is the right behavior. > > I'd say this patch here is a good example why it's not the right behaviour. > > This patch is making autoconf-archive allarch, i.e. lower priority than > before. In other words, anybody who has the previous TUNE_PKGARCH version > already will never get an update, even if the version number is bumped. > > 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
