Summary: | portage-2.2_rc23: usepkgonly fails with multilib packages | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Francisco J. Vazquez <dv> |
Component: | [OLD] Core system | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | polynomial-c, solar, zmedico |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 210077, 261959 |
Description
Francisco J. Vazquez
2009-03-08 11:28:22 UTC
Reassigning to portage team, CCing maintainer. It should work if you set this in make.conf: ACCEPT_CHOSTS="x86_64-pc-linux-gnu i686-pc-linux-gnu" I suppose we might want to add this setting to the amd64 profiles. However, in a way it defeats the purpose of ACCEPT_CHOSTS because it's conceivable that you wouldn't want to accept CHOST=i686-pc-linux-gnu from some packages... I'm told that the multilib_toolchain_setup function in multilib.eclass is what's responsible for changing the CHOST. This looks like the commit that broke it. http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/multilib.eclass?r1=1.71&r2=1.72 It should restore the environment before the pkgmgr saves the env. In svn r12810 I've added a QA Notice that is triggered if CHOST at install time differs from the initial CHOST setting. (In reply to comment #5) > In svn r12810 I've added a QA Notice that is triggered if CHOST at install time > differs from the initial CHOST setting. This warning is included in portage-2.2_rc24. (In reply to comment #4) > This looks like the commit that broke it. > http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/multilib.eclass?r1=1.71&r2=1.72 > > It should restore the environment before the pkgmgr saves the env. > I can make portage store the original CHOST, regardless of what the ebuild has done. Is that how we want to handle this? if anything, the package is more truthful about what's going on. these are packages which are not native to the default CHOST. they're native to the CHOST that the multilib function changed it to. until portage gets properly multilib support (which is probably never anyways), then feel free to simply ignore the CHOST after the emerge has started. note that i have no clue what this bug is about in the first place ... or what this "ACCEPT_CHOST" business is for ... (In reply to comment #8) > then feel free to simply ignore the CHOST after the emerge has started. Ok, we'll just ignore it then. It's fixed in svn r13088 to revert the CHOST to the initial value. This is fixed in 2.2_rc25 which is in package.mask. I'll close this bug when it's also released in 2.1.6.8. This is released in 2.1.6.8. |