1 |
Lluís Batlle i Rossell posted |
2 |
<20041202110107.GA27739@××××××××××××××××××.net>, excerpted below, on Thu, |
3 |
02 Dec 2004 12:01:07 +0100: |
4 |
|
5 |
> What I've tried, while answering this email: I've tried using 2004.3 => |
6 |
> Still keeps on using 2.4 (there are no virtual definitions in 2004.3!) |
7 |
> I've tried using default-linux/x86/2004.2/gcc34/2.6/ as profile => Even |
8 |
> this way emerge still keeps on using 2.4 |
9 |
> I've tried changing the content of the virtuals in default-linux and |
10 |
> default-linux/x86 => YES! Now it installs 2.6 headers. |
11 |
> |
12 |
> But... Shouldn't the other tries work ??? At least, you say that about |
13 |
> 2004.3, and the profile ....gcc34/2.6/ seems to have virtuals defined |
14 |
> there. |
15 |
|
16 |
OK, I see statements CG's statement that no x86 profile defaults to 2.6 |
17 |
headers for the virtuals, that he knows of, but you point out |
18 |
profiles/default-linux/x86/2004.2/gcc34/2.6/, as I did. |
19 |
|
20 |
Where a virtual is required, cascading profiles should read parent dirs |
21 |
until they find the default, if it's not in the current profile dir. Thus, |
22 |
the lack of a virtual definition file (or one not including all necessary |
23 |
virtuals) shouldn't be alarming, as it should just look up-tree to fill |
24 |
the requirement. |
25 |
|
26 |
Because profiles/default-linux/x86/2004.3 has a 2.4 subdir, and I'd seen |
27 |
discussion on the dev group/list on switching to 2.6 by default, I wrongly |
28 |
concluded 2004.3 on x86 had done so. It appears I was wrong. As you |
29 |
mention, there's no virtuals there, so it looks up-tree, to x86, where it |
30 |
finds virtual/linux-sources defaults to sys-kernel/gentoo-sources. That |
31 |
covers the kernel virtual default, but not headers, so it looks up-tree |
32 |
another notch, and finds them under default-linux, where |
33 |
virtual/os-headers defaults to sys-kernel/linux-headers. Note that it |
34 |
/also/ mentions virtual/kernel, defaulting that to |
35 |
sys-kernel/vanilla-sources. |
36 |
|
37 |
This means that we have three separate virtuals provided. |
38 |
virtual/os-headers defaults to the 2.4 series linux-headers. However, we |
39 |
have TWO DIFFERENT virtuals for kernel, virtual/kernel, and |
40 |
virtual/linux-sources. I'm GUESSING these should be one and the same, but |
41 |
in any case, they both default to 2.4 series kernels altho different |
42 |
branches of the series. Which one (or both) would try to be merged would |
43 |
therefore be dependent on which virtual individual packages called for. |
44 |
|
45 |
I thought to simplify matters, quickly clarifying which /should/ be used, |
46 |
by checking my arch, amd64. However, the virtuals file there only ADDS to |
47 |
the confusion, because instead of virtual/kernel pointing to a kernel, it |
48 |
points to headers. Of course the 2.4 kernel is depreciated on amd64, so |
49 |
everything points to 2.6 versions, but both virtual/os-headers and |
50 |
virtual/kernel point to sys-kernel/linux26-headers, while |
51 |
virtual/linux-sources points to sys-kernel/gentoo-dev-sources. |
52 |
|
53 |
Thus, virtual/kernel points to kernel sources in the one place, and only |
54 |
kernel headers in another, which is certainly confusing me! |
55 |
|
56 |
Anyway, back to x86, it indeed appears that |
57 |
profiles/default-linux/x86/2004.2/gcc34/2.6 defaults to 2.6 versions of |
58 |
both headers and kernel: |
59 |
virtual/kernel sys-kernel/linux26-headers |
60 |
virtual/os-headers sys-kernel/linux26-headers |
61 |
virtual/linux-sources sys-kernel/gentoo-dev-sources |
62 |
|
63 |
Hmm.. here too we have virtual/kernel pointing to headers, not sources, as |
64 |
in amd64, but NOT as the default-linux virtuals file, where virtual/kernel |
65 |
points to kernel sources instead of just kernel headers. |
66 |
|
67 |
Anyway, it would seem that profiles/default-linux/x86/2004.2/gcc34/2.6 |
68 |
does what you want, PROVIDED you don't have any problems with gcc-3.4, |
69 |
which is of course what the gcc34 refers to. That sub-profile defines all |
70 |
three virtuals, kernel, headers, and sources, to 2.6 defaults. |
71 |
|
72 |
Note that catalyst most likely will *NOT* notice the changed profile, |
73 |
unless you erase its previous tmp files. I'm suspecting that's the other |
74 |
problem you are experiencing now. It has its config, and doesn't go |
75 |
looking to change that, unless it disappears. Therefore, after changing |
76 |
your profile to the above 2004.2/gcc34/2.6, erase catalyst's temp files |
77 |
and see if it recreates them using the desired 2.6 minimals, now. |
78 |
|
79 |
Alternatively and the reason catalyst (again, presumably) works as it |
80 |
does, is that it allows you to modify its temp file virtuals once it gets |
81 |
past that point, thus allowing you to build a live-cd with a modified |
82 |
profile, without affecting the build-system's profile. Thus, instead of |
83 |
erasing the tmp files so catalyst sees the new configuration, consider |
84 |
editing the catalyst version directly instead. However, I'd say do as |
85 |
little editing here as possible, because it's possible tweaking one thing |
86 |
there will cause something else problems. An example would be tweaking |
87 |
the headers virtual to linux26-headers, while leaving the kernel at 2.4 |
88 |
virtuals. Gentoo's pre-built profiles should have those sort of |
89 |
dependencies worked out, while editing them could cause problems due to |
90 |
interlinking dependencies you weren't aware of when you did the editing. |
91 |
Thus, I'd recommend doing the above, change the system profile and erase |
92 |
catalyst's tmp files so it regenerates from that, instead of manually |
93 |
tweaking its profile, preventing potentially nasty surprises with |
94 |
conflicting dependencies. |
95 |
|
96 |
Also... you mention changing the content of the virtuals. You don't |
97 |
mention specifically /where/ you changed that content, in the catalyst |
98 |
temp files (OK), or directly in the portage tree itself (not so OK). The |
99 |
problem with changing it in the portage tree is that an emerge sync will |
100 |
erase the changes you made (unless you have rsync-ignore set on that dir, |
101 |
which creates problems of its own if Gentoo changes anything). For a |
102 |
one-shot catalyst build, and as long as you don't go doing an emerge sync |
103 |
while it's running, you should be fine, but just be aware that emerge sync |
104 |
/will/ erase changes you've made to the profiles in the portage tree |
105 |
itself. |
106 |
|
107 |
-- |
108 |
Duncan - List replies preferred. No HTML msgs. |
109 |
"They that can give up essential liberty to obtain a little |
110 |
temporary safety, deserve neither liberty nor safety." -- |
111 |
Benjamin Franklin |
112 |
|
113 |
|
114 |
|
115 |
-- |
116 |
gentoo-dev@g.o mailing list |