1 |
On Tuesday 21 October 2003 9:25, Thomas de Grenier de Latour wrote: |
2 |
|
3 |
> Because it is useful to be able to compile modules for a target kernel |
4 |
> that may be different than the running kernel, and a symlink is a |
5 |
> good way to point the target of your choice. |
6 |
|
7 |
Sure, that's an excellent point, but since the target kernel and the running |
8 |
kernel are likely on the same machine, and the current state of modules in |
9 |
portage IIRC isn't allowing the duplication of external modules packages, why |
10 |
not just be booted into the one you're making modules for? You're gonna end |
11 |
up rebooting either way eventually... |
12 |
|
13 |
> I don't see how system headers are related to modules compilation. The |
14 |
> flameable symlink is the /usr/include/linux, but it's a different issue. |
15 |
> It is something that on some other distros points on kernel includes |
16 |
> from kernel sources, but as you said, on Gentoo, we have a linux-headers |
17 |
> package and a real directory, so we do things the right way. |
18 |
|
19 |
The only modules discussion so far, other than what you recently brought up, |
20 |
was Mike's example of how the nvidia-modules package determined the running |
21 |
kernel. The original question was how does a package(generic) determine the |
22 |
running kernel. While I agree that there are some issues with the modules |
23 |
packages that should be handled differently, no package that doesn't provide |
24 |
modules should care what kernel you're running. But there are still a few |
25 |
packages in the tree that are using that /usr/src/linux symlink to get at |
26 |
includes (iproute2 until a while back, plex86 indirectly now,fex.) A nice |
27 |
solution for the modules packages might be to allow them to slot to the |
28 |
kernel version similar to the way you can specify USE, eg. SLOT="2.6.0-test8" |
29 |
emerge nvidia-modules and have it install the modules in /lib/${SLOT}/ (keep |
30 |
in mind, I have no idea how the nvidia-modules ebuild looks, thats just a |
31 |
general example). I also realize the main flameable link was the /usr/ |
32 |
include/{linux|asm} link pointing back to the kernel sources, but to quote |
33 |
Linus - |
34 |
" I would suggest that people who compile new kernels should: |
35 |
- NOT do so in /usr/src. Leave whatever kernel (probably only the |
36 |
header files) that the distribution came with there, but don't touch |
37 |
it. |
38 |
|
39 |
- compile the kernel in their own home directory, as their very own |
40 |
selves. No need to be root to compile the kernel. You need to be root |
41 |
to _install_ the kernel, but that's different. |
42 |
|
43 |
- not have a single symbolic link in sight (except the one that the |
44 |
kernel build itself sets up, namely the "linux/include/asm" symlink |
45 |
that is only used for the internal kernel compile itself)" |
46 |
|
47 |
1,2,3 things that haven't been done yet.. Personally I compile mine in /opt, |
48 |
because my /home is pretty full... |
49 |
-- |
50 |
Chuck Brewer |
51 |
Registered Linux User #284015 |
52 |
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred. |