Hi, please review the following two patches. Reproducible: Always
Created attachment 459058 [details, diff] indentation.patch Nothing but indentation.
Created attachment 459060 [details, diff] shortcut.patch shortcut for bootstrapping from Gentoo host or another Gentoo Prefix.
I'm not against this, but I see a lot of changes which feel to me like they break the normal bootstrap (non-creation of dirs, changes removing /tmp, etc). It seems to me if this is just skipping stage 1 and 2, that this should be much less invasive, e.g. by a new stage (stage_host_gentoo?) that does the necessary symlinking and leaving the original stages alone.
Created attachment 461790 [details, diff] host-gentoo.patch Good point Fabian. How about this patch?
Unfortunately you already committed it, so I had to fix up the breakage :(
(In reply to Fabian Groffen from comment #5) > Unfortunately you already committed it, so I had to fix up the breakage :( Sorry I didn't mean it and pushed it by accident. But it is tested on two systems. Hope it does not break too much. Feel free to revert any part.
Fabian, what is the rationale behind sanitizing PATH to /usr/bin:/bin? In some hosts, newer version of tools are found in /usr/local/bin. And host gentoo could be another Prefix to aid bootstrap. Would it be okay to let the user specify PATH?
(In reply to Benda Xu from comment #7) > Fabian, what is the rationale behind sanitizing PATH to /usr/bin:/bin? > > In some hosts, newer version of tools are found in /usr/local/bin. Some bell ringing here: /usr/local usually is the prefix various sysadmins use for their site-specific, self-compiled packages, and I've learned they usually do _not_ use any kind of package management there, nor they really grok enough about dependencies, sharedlibs, versions and similar. So we're better off not relying on /usr/local at all, but omitting it instead. > And host gentoo could be another Prefix to aid bootstrap. Yes, but we prevent users from bootstrapping somewhere into /usr/*, don't we?
(In reply to Michael Haubenwallner from comment #8) > (In reply to Benda Xu from comment #7) > > Fabian, what is the rationale behind sanitizing PATH to /usr/bin:/bin? > > > > In some hosts, newer version of tools are found in /usr/local/bin. > > Some bell ringing here: > /usr/local usually is the prefix various sysadmins use for their > site-specific, self-compiled packages, and I've learned they usually do > _not_ use any kind of package management there, nor they really grok enough > about dependencies, sharedlibs, versions and similar. So we're better off > not relying on /usr/local at all, but omitting it instead. Exactly. In the past this has proven to be a can of worms we need to avoid as much as we can. Providing a mechanism for people to override this if they (think they) know what they're doing is ok. > > And host gentoo could be another Prefix to aid bootstrap. > > Yes, but we prevent users from bootstrapping somewhere into /usr/*, don't we? Hmmm... do we? (eek!)
(In reply to Michael Haubenwallner from comment #8) > (In reply to Benda Xu from comment #7) > > Fabian, what is the rationale behind sanitizing PATH to /usr/bin:/bin? > > > > In some hosts, newer version of tools are found in /usr/local/bin. > > Some bell ringing here: > /usr/local usually is the prefix various sysadmins use for their > site-specific, self-compiled packages, and I've learned they usually do > _not_ use any kind of package management there, nor they really grok enough > about dependencies, sharedlibs, versions and similar. So we're better off > not relying on /usr/local at all, but omitting it instead. Administrator can do random things. Administrator of my institute has f**ked /bin/tar (symbols unresolvable) and compiled an alternative /usr/local/bin/gtar. I believe there are other cases. I am not arguing that we should rely on /usr/local, but that it is not a good idea to hard code PATH to /usr/bin:/bin. > > And host gentoo could be another Prefix to aid bootstrap. > > Yes, but we prevent users from bootstrapping somewhere into /usr/*, don't we? Okay, my point wasn't conveyed well. Let's consider this: I have a Gentoo Prefix under /opt/gentoo, and I would like to bootstrap another one into /home/xyz/gentoo. I would like the bootstrap script to keep /opt/gentoo/usr/bin in PATH, so that /opt/gentoo/usr/bin/emerge can replace stage2 portage.
(In reply to Benda Xu from comment #10) > I believe there are other cases. I am not arguing that we should rely on > /usr/local, but that it is not a good idea to hard code PATH to > /usr/bin:/bin. The reason to do this, is because bootstrap-prefix tries to be covering up as many problems as users can make. And users do. We know so, from the past. On purpose we try a minimal PATH, and only extend it for those platforms where we know we need to, to hopefully rely on some known/sane tools. The scenario you describe about a fscked up /bin/tar is aweful, but the exception rather than the rule. For your case I think we should allow some override (e.g. undocumented PREFIX_BOOTSTRAP_PRE_PATH) that we put in PATH first, but only to be used with extreme care/when you know what you're doing. Bootstraps in the early stages are often very fragile and weeding the environmental influences has hardened that stage a good bit.
(In reply to Fabian Groffen from comment #11) > (In reply to Benda Xu from comment #10) > > I believe there are other cases. I am not arguing that we should rely on > > /usr/local, but that it is not a good idea to hard code PATH to > > /usr/bin:/bin. > > The reason to do this, is because bootstrap-prefix tries to be covering up > as many problems as users can make. And users do. We know so, from the > past. On purpose we try a minimal PATH, and only extend it for those > platforms where we know we need to, to hopefully rely on some known/sane > tools. > > The scenario you describe about a fscked up /bin/tar is aweful, but the > exception rather than the rule. For your case I think we should allow some > override (e.g. undocumented PREFIX_BOOTSTRAP_PRE_PATH) that we put in PATH > first, but only to be used with extreme care/when you know what you're doing. > > Bootstraps in the early stages are often very fragile and weeding the > environmental influences has hardened that stage a good bit. Thanks for the explanation. Okay, let's keep status quo and revisite this later.
