JFYI, I've heard claims that "stage3 is resumable" but I guess not... bash-3.1$ ./bootstrap-prefix.sh "/tmp/jolexa/test" stage3 * Bootstrapping Gentoo prefixed portage installation using * host: x86_64-pc-linux-gnu * prefix: /tmp/jolexa/test * ready to bootstrap stage3 !!! emerge not found, did you bootstrap stage1 and stage2? bash-3.1$ ls usr/bin/ ebuild egencache emerge emerge-webrsync portageq quickpkg repoman bash-3.1$
if you come from the interactive installer, then yes, of course you never set PATH I'm thinking of something to create to pick up the settings from the installer
(In reply to comment #1) > if you come from the interactive installer, then yes, of course "of course" =P > you never set PATH shrugs, didn't know > > I'm thinking of something to create to pick up the settings from the > installer I set MAKEOPTS in my env and the installer didn't respect it, so I assumed that I really needed to "do nothing" for the installer.
(In reply to comment #2) > (In reply to comment #1) > > if you come from the interactive installer, then yes, of course > > "of course" =P > > > you never set PATH > > shrugs, didn't know http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml code listing 1.1 and 1.2 :) > > I'm thinking of something to create to pick up the settings from the > > installer > > I set MAKEOPTS in my env and the installer didn't respect it, so I assumed > that I really needed to "do nothing" for the installer. That's a different issue. What I mean is stageX to pick up/use env that the installer used as well, to be able to reliably continue. I had the same issue yesterday.
My idea is to save EPREFIX, CHOST, PATH, MAKEOPTS in a dot file that is checked/sourced.
Same idea here, problem is the logic when/how. What I do for the moment is just to start the installer with the same input (bits/prefix), then it resumes as well, in the same environment. I'd love to keep the envs in ${EPREFIX}, but the installer only asks this last (for a good reason), so by that time the envs are no longer necessary. Another idea that I had was to extend the error message with instructions on how to resume, which could be to run the "resume" target, ./bootstrap-prefix.sh ${EPREFIX} resume
... on the "resume" idea ... could even overload it such that you can do ./bootstrap-prefix.sh /var/prefix resume i686-pc-linux-gnu -j2 /usr/local/gnu:/usr/xsh4/bin to not really resume (if there is nothing to resume), but start a new bootstrap with ingredients as given, taken as don't ask defaults by the interactive installer.
I'd need something like that to perform weekly automagic bootstraps anyway, so there's only place where all bootstrap logic is encoded.
The installer evolved since somewhat, resuming in general works, but it will never be fool-proof.
