I just started a new Gentoo installation. I edited make.conf according to the instructions and included ACCEPT_KEYWORDS="~x86". I intended to time the compilation process, so before bootstraping I edited bootstrap.sh, changed all 'emerge <something>' lines to 'emerge -f <somethimg>' and executed it, so I could exclude downloading times from the measurements. All went fine in this step. I then restored the original bootstrap.sh and executed it. Strangely enough, it started to download texinfo-4.2.tar.gz, despite it had already downloaded texinfo-4.3.tar.gz before. I stopped it, restored make.conf from make.conf.build, edited bootstrap.sh again and commented out the line that emerges portage (it was already emerged) and ran it again. It then started to build texinfo-4.3 as expected. I then checked and noticed that texinfo-4.3.ebuild currently had "~x86" included in the KEYWORDS. The conclusion is that when make.conf was overwritten, my ACCEPT_KEYWORDS="~x86" was thrown away. Maybe the original make.conf should be restored right after emerging portage, and not just in the end of the whole process.
This is known, and maybe wanted behaviour, as you want bootstrap to be under known to work conditions .... What I usually do is add it to my /etc/make.profile/make.defaults ...
export it in your environment if you want to build your box unstable.
Please forgive me if I got an incorrect impression, but it looks like you are trying to convince me that it was my fault if Portage didn't respect the settings I chose, because I shouldn'd have chosen those settings anyway. I don't want to seem rude, but I'd like to refer to some portions of the Gentoo's website contents. Quoting <http://www.gentoo.org/main/en/about.xml>: "He discovered lots of up-to-date packages that could be auto-built using the optimizations settings and build-time functionality that he wanted, rather than what some distro creator thought would be best for him. All of the sudden, Larry the Cow was in control. And he liked it." "Portage allows you to set up Gentoo Linux the way you like it -- with the optimization settings that you want, and with optional build-time functionality (like GNOME, KDE, mysql, ALSA, LDAP support, etc.) enabled or disabled as you desire." "You decide what kind of system you want, and Portage will create it for you." "the resultant installed binaries will be optimized and customized to your exact specifications." Also, in <http://www.gentoo.org/doc/en/gentoo-x86-install.xml>, step 11 is where I set up my make.conf, and step 12 is where bootstraping takes place. I see no reason for step 12 to ignore what was set up in step 11. I understand why make.conf is overwritten, and this is expected. That's why CHOST, CFLAGS, CXXFLAGS and friends are saved before emerging Portage, right? So, again, please correct me if I'm wrong, but I believe that restoring the original make.conf right after Portage is emerged in bootstrap.sh would fix this issue, and probably any other that would arise when new variables get added to make.conf. Thanks for your attention.
Because bootstrap is very fragile, we make sure that its merged with *tested* USE flags ... This is where the moving of make.conf comes in. It is also because some wierd setting in make.conf could cause bootstrap to fail, and its a lot more time to get it running again than say 'emerge system'. Now, because CFLAGS and CXXFLAGS are exported in bootstrap.sh, those are what gets used to compile the packages that gets merged during bootstrap.sh. Thus its *only* USE flags that are different from what you set. At the end of bootstap, your original make.conf is restored, and the 'emerge system', etc is done with that. Now, you may argue that we force you to use the USE flags for bootstrap that we have chosen ... on the other hand, think about this: Because its not a precompiled Distro, *you* can still edit bootstrap.sh to suite your needs. And this is why we try to keep things simple in most cases .. to give the user the chance to change stuff to suite him, without having to dig through to much fluff. On the other hand, if you do reach this level of experience to make changes to bootstrap.sh, or any other file/ebuild, we *do* expect you to first check with vanilla scripts/ebuilds if its not due to your hacking that things broke. So to conclude: 1) Yes, we do force our USE flags on you during bootstrap, but you can edit bootstrap.sh if you really like. Its more to make the experience of first time users thus the better that we do this. 2) In theory, your make.conf should be restroed afterwards, and the rest done as you selected. This is of course excluding the cases we know of that some flags may cause failure in a particular ebuild or unstability.
Azarah is very right here If it doesn't have USE="-* build", as forced in bootstrap.sh things will just pain not work properly (non-static things for a bootsrap is not a pretty scenerio) :)
There has recently been a discussion about this on gentoo-dev. Good points were raised there. This is a link to the start of the thread: http://article.gmane.org/gmane.linux.gentoo.devel/7383
Portage will no longer install /etc/make.conf if 'build' or 'bootstrap' in USE.
