Any changes made to /etc/make.conf before running scripts/bootstrap.sh are lost as a new make.conf overwrites the modified /etc/make.conf. If this is now the intended behaviour then the install docs need to be updated to reflect this.
Hmm not this discussion again, there are several other (long threaded) bugs that deal with this.. this is expected behaviour, and in fact your original settings still get used and the original file gets replaced at end of process Is your make.conf not restored at end of bootstrap?
Thanks, everything seems to be correct then. Maybe a list of changes to previous default behaviour when running bootstrap would reduce unnecessary bug reports.
Gerk, the trap stuff dont get the ^C ... dunno if you wanna have a look, but for some reason here it dont do what it should .....
I think I know exactly what the issue is here now that I look at things.. but I'm not sure an elegant way to solve it... This issue is that when you cntrl+c it kills the _current_ process running (which may or may not be the bootstrap.sh script.. most likely not).... this is the same reason that portage doesnt always return proper error codes. When these sub processes get killed thusly, you drop to a shell instead of returning to the parent process. Now to get around this I'm not sure yet.. unless we somehow build traps into portage? I'm not sure this would even work, especially given the amount of subshelling and stuff that can happen during any given ebuild, we would almost have to trap cntrl+c globally (which is a bad idea methinks) Maybe we have to investigate a different approach to use for this. Will think on this some more. Shuffling some things from baselayout may be a solution? provide a make.conf.new from baselayout and deal with it at end of process? (kind of a cludge too)
Portage takes hold of the interrupt hooks via python, and that is why its not working. New versions of portage will not replace make.conf if 'build' in USE. CLosing.
