Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 434268

Summary: dev-util/catalyst: custom CHOST vs stage3+
Product: Gentoo Hosted Projects Reporter: SpanKY <vapier>
Component: CatalystAssignee: Gentoo Catalyst Developers <catalyst>
Status: CONFIRMED ---    
Severity: normal    
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on: 679386, 538648    
Bug Blocks:    

Description SpanKY gentoo-dev 2012-09-07 23:12:17 UTC
it seems that the stage3+ target of catalyst no longer supports setting chost via the spec file.  i think the idea is that you shouldn't be changing the chost between stage2 and stage3.  that's fine.

the problem is that chosts that catalyst itself doesn't know about are no longer usable.  you can inject your crazy chost name into stage1 and stage2 and they'll get used, but since the stage3 catalyst doesn't *preserve* the chost itself from the input stage (it always clobbers it with whatever value it has hardcoded in its arch modules), you end up changing chost values anyways.

this system doesn't work.  two possible ways out:
 - respect chost with stage3+ specs (again) and just warn about changing chosts (thus making it a user problem)
 - have catalyst detect the CHOST setting from the input stage and then use that instead of always clobbering with its own CHOST setting from the arch .py
Comment 1 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2012-09-30 22:38:43 UTC
find . -type f -exec grep -H -i chost {} \;
./targets/support/chroot-functions.sh:          CHOST=$(portageq envvar CHOST)
...
./modules/stage1_target.py:             self.valid_values=["chost"]
./modules/stage1_target.py:     def override_chost(self):
./modules/stage1_target.py:             if self.settings.has_key("chost"):
./modules/stage1_target.py:                     self.settings["CHOST"]=list_to_string(self.settings["chost"])
./modules/stage2_target.py:             self.valid_values=["chost"]
./modules/stage2_target.py:     def override_chost(self):
./modules/stage2_target.py:             if self.settings.has_key("chost"):
./modules/stage2_target.py:                     self.settings["CHOST"]=list_to_string(self.settings["chost"])

So it seems only stage1 and stage2 allow the definition of chost in the spec file (as you said) and that all other targets pick chost from the existing config - which seems to contradict your findings. We'll have to check why stage3+ are not using the existing CHOST definition (the one in the seed stage make.conf).