On 30/08/2016 11:25, Peter Humphrey wrote: > On Tuesday 30 Aug 2016 00:07:53 Alan McKinnon wrote: > >> Don't forget that @system only lives in a context, and the context is a >> real computer. >> >> Out of context it's just a list of strings. In context, it's strings >> that means packages, with deps and everything else that needs to be >> built for @system to mean anything on the machine it's added to. >> >> One never needs to define @system, that is already done in a profile so >> it's not something that means sense to migrate or re-use elsewhere. >> Don't worry about @system, worry about USE and get that right. Emerge >> will deal with what it takes to give the user the @system he's really >> asking for. >> >> Or maybe I don't completely understand yet Peter's actual question. > > Hmm. I do seem to have a knack of not saying quite what I mean these days. > > I want to define a minimal set to make sure the tool chain is correct and > free of faults, not just up to date, before doing anything else. Then I can > use that to build whatever other parts of the system I may be suspicious of. > I know that portage will work out a good order of battle, but it assumes > correctness in the tool chain: its job is to keep the system current. If > there is a problem in the tools, it's going to cause problems when the rest > of the system is built. > > Quite a while ago I came across some advice to emerge gcc first, then glibc > and libtool, then whatever else is needed (@system, @world etc). I've been > doing that, but it does seem a bit minimal. That's why I thought of this > sysbase idea. > > You may wonder why I suspect my system at all. The reason is an intermittent > series of apparently unrelated things going wrong. This box is only six > months old and it contains some very recent hardware, and I'm not quite > convinced that I have everything set up just right. >
You have been given silly advice because things just do not work that way. The set you want is @system. It looks like you want to guarantee that portage's tools are 100% correct so that portage can be assured it is using good stuff. But the tool that you use to build those tools and get them correct is portage itself :-) There are only 3 ways to get a new improved toolchain: - use a stage 3 which provides one - use a stage 1 and do the whole thing by hand - use portage There's nothing wrong with using #3. Portage doesn't use the toolchain much to get things going as it's python. As long as you have a decent working python you are pretty much good to go. Of course it may use the existing toolchain to rebuild the toolchain so you need to have a toolchain first - which you get from a stage 1 or stage 3. In any event, it's not just a case of building gcc - to get the latest version portage needs curl, wget, zlib, tar and a bucket load of other stuff t even fetch the code. Then it needs autotools and everything else make uses to build it. So really you are trying to fix a suspect system by rebuilding a good system using the suspect system. And that just ain't never gonna work. Maybe in some other universe, but not this one. Just rebuild @system and let portage do it's thing - the result you will get is exactly the same you will have after you update all of world, and that is the toolchain you will use forever more. Any and all advice you stumble across about rebuilding gcc and glibc and stuff is nonsense, backwards and going the wrong way. You should elaborate more and be specific on what you mean by "The reason is an intermittent series of apparently unrelated things going wrong." Work the real problem, not an assumed one :-) -- Alan McKinnon alan.mckin...@gmail.com
