1 |
OK, I take it back. |
2 |
|
3 |
I said that the situation of upgrading a kernel with the 'symlink' USE |
4 |
flag active occurring at the same time as a (particular) program needing |
5 |
to compile against a configured kernel was not likely to occur all that |
6 |
often, but I was wrong. It's happened again today, but with a different |
7 |
program than the ones I normally keep an eye on. |
8 |
|
9 |
The good thing is that I (think I) see what the problem is. |
10 |
|
11 |
The problem is that Portage emerges the new kernel before (almost) |
12 |
everything else, without regard for whether the 'symlink' USE flag is |
13 |
active, and whether or not any of the other programs proposed to emerge |
14 |
need to compile against a configured kernel source-- or rather, the |
15 |
currently-running kernel, which the symlink most likely pointed to |
16 |
before Portage changed it via a previous emerge. |
17 |
|
18 |
Honestly, there's really no reason (that I can see) to emerge a kernel |
19 |
source before everything else, since the kernel source is useless until |
20 |
at the very least configured, and preferably compiled and installed, and |
21 |
since you're in the middle of an emerge -uwhatever world, you can't |
22 |
reasonably configure and compile the new source until the entire |
23 |
operation is finished. Yeah, OK, technically you can, but it's not |
24 |
really something that an ordinary person would do, I think. |
25 |
|
26 |
And if the 'symlink' USE flag is active, emerging the kernel sources |
27 |
before everything else-- which may include packages that must compile |
28 |
against a configured kernel, with the assumption that the |
29 |
/usr/src/symlink points to such a kernel, which it no longer does |
30 |
because the symlink has been changed during a previous emerge and you |
31 |
have not had time to configure the newly-emerged kernel-- is a real |
32 |
problem. I just had to open another term, su to root, run MC to change |
33 |
the symlink-- and got it wrong because I had a second unconfigured |
34 |
kernel (2.6.14-r2; 2.6.14-r3 was being installed) that I forgot I had |
35 |
not yet upgraded to), so had to change the link again to the *real* |
36 |
running kernel (2.6.14) and emerge --resume. And of course I'll have to |
37 |
eventually change the symlink back manually in order to actually manage |
38 |
the new kernel. Which means I have to remember to do that-- which is not |
39 |
the point of having the 'symlink' USE flag active. |
40 |
|
41 |
It seems to me that this could all be avoided if Portage emerged a new |
42 |
kernel *last* in the list if the 'symlink' USE flag is active for kernel |
43 |
emerges-- then everything in the list that needed a configured kernel |
44 |
would have one (the currently-running kernel), the emerge would complete |
45 |
normally, and the symlink would be changed at the end of the procedure |
46 |
so that my next operation could be to upgrade the kernel, which seems to |
47 |
me a reasonable and ordinary order of operation (emerge -u** world, then |
48 |
configure and compile new kernel and run module-rebuild). |
49 |
|
50 |
Am I doing things wrong, or is this a valid enhancement request for b.g.o? |
51 |
|
52 |
Holly |
53 |
-- |
54 |
gentoo-user@g.o mailing list |