1 |
On 30/08/2016 11:25, Peter Humphrey wrote: |
2 |
> On Tuesday 30 Aug 2016 00:07:53 Alan McKinnon wrote: |
3 |
> |
4 |
>> Don't forget that @system only lives in a context, and the context is a |
5 |
>> real computer. |
6 |
>> |
7 |
>> Out of context it's just a list of strings. In context, it's strings |
8 |
>> that means packages, with deps and everything else that needs to be |
9 |
>> built for @system to mean anything on the machine it's added to. |
10 |
>> |
11 |
>> One never needs to define @system, that is already done in a profile so |
12 |
>> it's not something that means sense to migrate or re-use elsewhere. |
13 |
>> Don't worry about @system, worry about USE and get that right. Emerge |
14 |
>> will deal with what it takes to give the user the @system he's really |
15 |
>> asking for. |
16 |
>> |
17 |
>> Or maybe I don't completely understand yet Peter's actual question. |
18 |
> |
19 |
> Hmm. I do seem to have a knack of not saying quite what I mean these days. |
20 |
> |
21 |
> I want to define a minimal set to make sure the tool chain is correct and |
22 |
> free of faults, not just up to date, before doing anything else. Then I can |
23 |
> use that to build whatever other parts of the system I may be suspicious of. |
24 |
> I know that portage will work out a good order of battle, but it assumes |
25 |
> correctness in the tool chain: its job is to keep the system current. If |
26 |
> there is a problem in the tools, it's going to cause problems when the rest |
27 |
> of the system is built. |
28 |
> |
29 |
> Quite a while ago I came across some advice to emerge gcc first, then glibc |
30 |
> and libtool, then whatever else is needed (@system, @world etc). I've been |
31 |
> doing that, but it does seem a bit minimal. That's why I thought of this |
32 |
> sysbase idea. |
33 |
> |
34 |
> You may wonder why I suspect my system at all. The reason is an intermittent |
35 |
> series of apparently unrelated things going wrong. This box is only six |
36 |
> months old and it contains some very recent hardware, and I'm not quite |
37 |
> convinced that I have everything set up just right. |
38 |
> |
39 |
|
40 |
You have been given silly advice because things just do not work that |
41 |
way. The set you want is @system. |
42 |
|
43 |
It looks like you want to guarantee that portage's tools are 100% |
44 |
correct so that portage can be assured it is using good stuff. But the |
45 |
tool that you use to build those tools and get them correct is portage |
46 |
itself :-) |
47 |
|
48 |
There are only 3 ways to get a new improved toolchain: |
49 |
|
50 |
- use a stage 3 which provides one |
51 |
- use a stage 1 and do the whole thing by hand |
52 |
- use portage |
53 |
|
54 |
There's nothing wrong with using #3. Portage doesn't use the toolchain |
55 |
much to get things going as it's python. As long as you have a decent |
56 |
working python you are pretty much good to go. Of course it may use the |
57 |
existing toolchain to rebuild the toolchain so you need to have a |
58 |
toolchain first - which you get from a stage 1 or stage 3. |
59 |
|
60 |
In any event, it's not just a case of building gcc - to get the latest |
61 |
version portage needs curl, wget, zlib, tar and a bucket load of other |
62 |
stuff t even fetch the code. Then it needs autotools and everything else |
63 |
make uses to build it. |
64 |
|
65 |
So really you are trying to fix a suspect system by rebuilding a good |
66 |
system using the suspect system. And that just ain't never gonna work. |
67 |
Maybe in some other universe, but not this one. |
68 |
|
69 |
Just rebuild @system and let portage do it's thing - the result you will |
70 |
get is exactly the same you will have after you update all of world, and |
71 |
that is the toolchain you will use forever more. Any and all advice you |
72 |
stumble across about rebuilding gcc and glibc and stuff is nonsense, |
73 |
backwards and going the wrong way. |
74 |
|
75 |
|
76 |
You should elaborate more and be specific on what you mean by "The |
77 |
reason is an intermittent series of apparently unrelated things going |
78 |
wrong." |
79 |
|
80 |
Work the real problem, not an assumed one :-) |
81 |
|
82 |
|
83 |
-- |
84 |
Alan McKinnon |
85 |
alan.mckinnon@×××××.com |