1 |
On Sunday 05 October 2003 18:53, Luke-Jr wrote: |
2 |
> -----BEGIN PGP SIGNED MESSAGE----- |
3 |
> Hash: SHA1 |
4 |
> |
5 |
> On Sunday 05 October 2003 02:47 pm, Jason Stubbs wrote: |
6 |
> > > I although don't suggest that -src |
7 |
> > > suffix, but an option to the emerge, which tells it to install |
8 |
> > > this software to package's SLOT="$P-src", from which I then could |
9 |
> > > be looking in $PORT_SRC_DIR/$P-src. |
10 |
> > |
11 |
> > Agreed here. An option to emerge is much more intuitive. |
12 |
> |
13 |
> However, it prevents packages from DEPENDing on it. For example, if |
14 |
> the kernels were to ever use the genkernel thing, nvidia-kernel might |
15 |
> DEPEND on nvidia-kernel if it actually needed the source for it. I |
16 |
> also don't think it should automaticly provide the package it is the |
17 |
> source for until the user uses ebuild to install/merge it into the |
18 |
> system. |
19 |
|
20 |
Those modules can only be compiled to kernels that already has a |
21 |
dependecy information made. So in older kernels this means make dep and |
22 |
never kernels needs the config process done. After this point the |
23 |
kernel include dir, which these packages need can be used. |
24 |
|
25 |
The guestion is how would we manage the finding of the kernel include |
26 |
dir for the source installed version. As I proposed the env variable |
27 |
could be used if the user want's to build the package for different |
28 |
kernel than the currently running kernel. |
29 |
|
30 |
This would be good in other perspective too. Say we install new kernel |
31 |
linux-2.6.0-test18 through this new version of portage. So it would |
32 |
compile and install the kernel it's modules and the include tree. After |
33 |
this portage could compile the module packages present in system to |
34 |
this new kernel and add the module files to the module dir and to the |
35 |
packages CONTENT file, so that all of the made modules would be removed |
36 |
in a case where the corresponding package is removed from the system. |
37 |
So Portage could set this kernel source variable to correct location |
38 |
before compiling the module packages. |
39 |
|
40 |
The variable should be kernel_includes or something, because that's |
41 |
what the packages need not the full source tree. |
42 |
As an example the NVidia kernel module needs quite many header files to |
43 |
determine the correct sizes of many kernel type definitions. And some |
44 |
configuration information like was the kernel compiled with SMP support |
45 |
or not. This all can be retrived from the kernel include dir and it's |
46 |
sub directories. |
47 |
|
48 |
> > > Oh and the kernel packages that would compile the kernel should |
49 |
> > > install the kernel headers of the compiled kernel to |
50 |
> > > /usr/src/linux-`uname -r`/include/ |
51 |
> > > so that any package that needs the real kernel headers can find |
52 |
> > > them. |
53 |
> > |
54 |
> > Er, I'm pretty sure that the packages that need the source in |
55 |
> > /usr/src/linux need more than just the headers - but don't quote me |
56 |
> > on that! |
57 |
> |
58 |
> I can't think of any valid reason they would need to do so, but I've |
59 |
> never done much of anything with the kernel. |
60 |
|
61 |
Well that kind of perversive package will borke very fast. |
62 |
And besides only thing I can think of that would need the kernel source |
63 |
location is patch to kernel, but those should be delt before the kernel |
64 |
installation not after. |
65 |
|
66 |
|
67 |
|
68 |
-- |
69 |
gentoo-dev@g.o mailing list |