Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 434268 - dev-util/catalyst: custom CHOST vs stage3+
Summary: dev-util/catalyst: custom CHOST vs stage3+
Status: CONFIRMED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: Catalyst (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Catalyst Developers
URL:
Whiteboard:
Keywords:
Depends on: 679386 538648
Blocks:
  Show dependency tree
 
Reported: 2012-09-07 23:12 UTC by SpanKY
Modified: 2019-03-04 06:52 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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).