1 |
Ben Munat wrote: |
2 |
> Great. This sounds like a major disaster in the making. I'm glad I |
3 |
> asked... but I wonder how many people running a 2.4 kernel have just |
4 |
> hosed their systems? |
5 |
|
6 |
Well yes, I suppose it would be pretty bad if you were to inadvertently |
7 |
install 2.6 headers and later build glibc against them while still |
8 |
continuing to run a 2.4 kernel :o |
9 |
|
10 |
> One interesting thing: The version grid for linux-headers on |
11 |
> packages.gentoo.org now shows version 2.4.22-r1 as the latest available |
12 |
> version. The two 2.6 versions are hard masked: |
13 |
> |
14 |
> http://packages.gentoo.org/search/?sstring=linux-headers&sourceid=mozilla-search |
15 |
> |
16 |
> |
17 |
> However, I just synced again and emerge still wants to upgrade my linux |
18 |
> headers to 2.6.8.1-r2... even though the website lists this as hard masked! |
19 |
|
20 |
That's easy - the website is wrong ;) 2.6.8.1-r2 is not masked at all |
21 |
(this change was made very recently in accordance with the 2005.0 |
22 |
release). Basically, 2.6 kernels are now the default on some arches in |
23 |
the stock 2005 profile. |
24 |
|
25 |
> As far as the make.profile stuff goes, do I have to change to the 2005.0 |
26 |
> profile? I was never trying to upgrade to a new profile; I just thought |
27 |
> it odd that portage wanted to emerge what sounded like the wrong headers |
28 |
> package for my system (and it turns out I was right). I just looked and |
29 |
> I'm actually still pointing at the 2004.0 profile. Is this bad? |
30 |
|
31 |
No, not really. Just bear in mind that one day the profile you're using |
32 |
will disappear from portage whereupon it will whine at you. Thus, a |
33 |
change will be necessitated. |
34 |
|
35 |
> As for rebuilding packages after emerging linux-headers, I don't want to |
36 |
> emerge linux-headers! Really nice one-liner there though. |
37 |
|
38 |
Sure. |
39 |
|
40 |
> So, I'm figuring I should mask >=linux-headers-2.5 like Sri suggested. |
41 |
> But I suppose that still leaves me with the question as to what to do |
42 |
> about my make.profile. Is it important to change that with each new |
43 |
> release? (And if so, shouldn't portage remind me if it's so important?) |
44 |
> What are people running for their make.profile? |
45 |
|
46 |
No, it's not overly important in many cases, at least for x86 arch. |
47 |
Conversely, it's not advisable to remain on a deprecated profile for too |
48 |
long. If you poke around in the profile, you'll see that its task is |
49 |
mainly to establish such things as default USE flags, packages that |
50 |
constitute the "system" set, minimum acceptable package versions thereof |
51 |
, default virtuals (i.e. what does it choose if you emerge something |
52 |
that depends on virtual/kernel and no suitable ebuild has been emerged) |
53 |
etc. All in all, this defines a baseline policy for how gentoo is built |
54 |
and "evolved" and one would generally do well to follow the bottom line |
55 |
there I suspect. I still haven't shifted from the 2004.3 profile on my |
56 |
server but will do so shortly. |
57 |
|
58 |
If you use the profile I suggested then you shouldn't have to mask |
59 |
anything, although I'm not certain that the sources you are using are |
60 |
restricted as you would wish (see |
61 |
/usr/portage/profiles/default-linux/x86/2005.0/2.4/packages). As I |
62 |
mentioned before, you could rectify that eventuality by either |
63 |
overriding the "packages" file in a PORTDIR_OVERLAY or by adding your |
64 |
own sub-directory under 2.4 (again, in a PORTDIR_OVERLAY) and |
65 |
restricting the scope of the sources (gss-sources, was it?) there. In th |
66 |
e latter case, you'd need to make sure that make.profile pointed to the |
67 |
sub-directory that you defined. Or you could just use package.mask as |
68 |
per usual. In any case, understanding the profile mechanism and how to |
69 |
customise it is a useful asset to have in terms of Gentoo management. |
70 |
|
71 |
To explain futher, remember that profiles are cascaded. So, for example, |
72 |
the 2.4 profile isn't defined by just the three files you see there. |
73 |
Files from parent directories are also inherited/overridden as |
74 |
necessary. As with anything else in the portage tree, any aspect can be |
75 |
augmented or overriden in a local overlay so it makes for quite a |
76 |
flexible system. |
77 |
|
78 |
HTH, |
79 |
|
80 |
--Kerin Francis Millar |
81 |
-- |
82 |
gentoo-server@g.o mailing list |