bootstrap.sh overwrites your modified /etc/make.conf with one containing default values. It restores your personal one if bootstrap.sh finishes successfully, but not if it aborts with an error.
This could be a real problem if the machine is behind a Draconian firewall requiring use of a HTTP proxy. Because the file is trashed, wget never sees the values of RSYNC_PROXY, HTTP_PROXY and FTP_PROXY that are set in it. For some reason, the fact that bootstrap.sh exports these variables doesn't seem to have an effect. Perhaps this in itself is another bug. I suspect that also means that the newly-bootstrapped system is also not optimised for the architecture. I'd like the severity increased on this one.
The one that is used by bootstrap.sh is /etc/make.conf.build I plugged my cpu specific settings in here and after a few attempts was able to bootrap on a K6-2 450. Once I got the kernel .config right. The gentoo.org/doc/build.html says edit make.conf and install.txt on the iso had these instructions.I did this and it overwrote the settings I had put in /etc/make.conf with those from make.conf.build I suppose thre is a reason for making this file a moving target but ...
The one that is used by bootstrap.sh is /etc/make.conf.build I plugged my cpu specific settings in here and bootrap on a K6-2 450. The gentoo.org/doc/build.html says edit make.conf and install.txt on the iso had these instructions.I did this and it overwrote the settings I had put in /etc/make.conf with those from make.conf.build I suppose thre is a reason for making this file a moving target but ...
Check it again. It keeps your CFLAGS, etc, but just redo make.conf to have USE flags that is known to work in there. As for the proxy settings .. not sure. After successful bootstrap, it restores your make.conf.
I don't see the big problem here to be honest. If your bootstrap fails, you can replace the make.conf with /etc/make.conf.build (the copy of your make.conf file). Also if your bootstrap fails, it should clean this up. If you manually _stop_ (i.e. cntrl+c your bootstrap) it doesn't get replaced. AFAIC this is not a bug.
> If your bootstrap fails, you > can replace the make.conf with /etc/make.conf.build Yes, if you know about the problem. A newbie wont any idea that the bootstapping process will overwite the file that the install instructions just asked him to edit. If nothing gets changed, a note about this in the installation guide would be a small help. It would be nice if bootstap restored the file whether it fails or succeeds. It would be nicer if it didnt have to replace the file at all (perhaps using an environment variable to override the relevant settings). That would improve the explainability of the process.
the bootstrap script does restore this is many cases, except in the build fails incorrectly (i.e. without a || die on a part of ebuild), or at least should afaik. The only other time it will not replace is if you manually stop the bootstrap process with cntrl+c. I'll cc some docs people here, as i think it is defaintely worth a mention in install stuffs :)
It should restore the original except if you "ctrl-c" it, even if bootstrap fails.
To be honest, I do not see the whole issue here. I have done many bootstraps, and the only times it did not restore it, was on a ctrl-c. If that is a problem for you, then its easy to fix .. just install the cleanup function as a signal handler: ----------------------- trap "cleanup" INT TSTP -----------------------
Forgive me if I miss something, but I think the issue is more serious. In addition to proxy settings, the bootstrap script would also overwrite CHOST & CFLAGS settings. This is a serious issue when cross-compiling, because if the machine the distribution is built on is more recent than the one it should run on (a good reason for cross-compiling IMHO), the result will be unusable on the target machine. So it's not only an issue of restoring the make.conf file, but more of taking the changes into account. I thus agree that the severity should be increased.
Oops! Sorry, just found out about bug 9324.
Martin added teh contrl+c signal handler some time ago, marking this bug closed
For comment #10. I think you should reread the script. It does NOT overwrite CFLAGS, etc. It only TEMPORARY overwrite make.conf to have USE flags that are KNOWN to WORK! See snippit: ----- #get correct CFLAGS, CHOST, CXXFLAGS, MAKEOPTS since make.conf will be #overwritten cp /etc/make.conf /etc/make.conf.build export CFLAGS="`$PYTHON -c 'import portage; print portage.settings["CFLAGS"];'`" export CHOST="`$PYTHON -c 'import portage; print portage.settings["CHOST"];'`" export CXXFLAGS="`$PYTHON -c 'import portage; print portage.settings["CXXFLAGS"];'`" export MAKEOPTS="`$PYTHON -c 'import portage; print portage.settings["MAKEOPTS"];'`" PROXY="`$PYTHON -c 'import portage; print portage.settings["PROXY"];'`" if [ -n "${PROXY}" ] then echo "exporting PROXY=${PROXY}" export PROXY fi HTTP_PROXY="`$PYTHON -c 'import portage; print portage.settings["HTTP_PROXY"];'`" if [ -n "${HTTP_PROXY}" ] then echo "exporting HTTP_PROXY=${HTTP_PROXY}" export HTTP_PROXY fi FTP_PROXY="`$PYTHON -c 'import portage; print portage.settings["FTP_PROXY"];'`" if [ -n "${FTP_PROXY}" ] then echo "exporting FTP_PROXY=${FTP_PROXY}" export FTP_PROXY fi -----------
assigned/fixed borks the database,changing to resolved:fixed. //ZhEN
To actually resolve this issue I belive that either: The installation instructions should make mention to this or be changed so the editing of make.conf is the step AFTER bootstrap.sh runs. bootstrap.sh should be modified or should find a way to "have USE flags that are KNOWN to WORK" without overwriting the make.conf.
This is NOT AN ERROR. It is by design. Please RTFM before re-opening bugs like this. Again this is NOT A PROBLEM. It is moved, and replaced seemlessly, sheeeeeesh. Even cntrl+c is now trapped so it is replaced if you decide to exit bootstrap.sh prematurely. What you propose is not feasible. THere are more reasons for this that I really don't want to take the time to get into, but I'll give you a hint, look at CONFIG_PROTECT and the fact that you dont run that during bootstrap and you'll see this is done to PROTECT your make.conf settings. Closing this again, plese, do NOT re-open this bug. THis is 4th go around on this now. THe real bug part of it was fixed long ago.
Moving these so we can remove the "Install CD" component from "Gentoo Linux". I apologize to everyone for this spam, but according to the bugzilla developers, this is the only reasonable way to do this.
