--- xml/htdocs/proj/en/glep/glep-0026.html 2004/11/11 21:32:30 1.2 +++ xml/htdocs/proj/en/glep/glep-0026.html 2006/10/10 20:25:14 1.3 @@ -8,9 +8,252 @@ -->- +
|Author:||Nathaniel McCallum <npmccallum at gentoo.org>, Joshua Campbell <warpzero at gentoo.org>|
This GLEP proposes to create a more consistent handling of kernels and kernel building. Currently "emerge kernel-name" only installs the sources and does not build anything. -"emerge kernel-name" should install only sources OR only a binary kernel, its modules, +"emerge kernel-name" should install only sources OR only a binary kernel, its modules, and a tarballed package of kernel-headers, depending on USE flag.
Currently, the only automated kernel build proceedure that we have is genkernel. While genkernel is a great tool, its main weakness is that it does not port well to other arches because of the initrd and the lack of good "generic" settings for other arches. This GLEP hopes to overcome this by abstracting the various layers of genkernel and implementing the most common aspect (the build proceedure) into a portage eclass.
There would be 3 layers to kernel building: (place of implementation)
@@ -98,13 +340,13 @@
Stage 1 would be achieved through a seperate utility (perhaps like the current genkernel). This utility would help the user configure the kernel and any kernel/build related settings. This stage is optional and would only be used if a person wanted a -customized kernel settings. One optional thought is to have this utility a part of the +customized kernel settings. One optional thought is to have this utility a part of the base Gentoo system. That way there are less steps to make a custom kernel.
Stage 2 would be implimented through an eclass. This stage is not optional. One would perform this step by typing "emerge kernel-name", where "kernel-name" is the name of the kernel package you want to use (ie. "gentoo-dev"). This package would have a "buildkernel" USE flag. If the flag was not set, it would simply download and install -sources like we do currently. However, if the "buildkernel" flag is set, portage will +sources like we do currently. However, if the "buildkernel" flag is set, portage will perform the following steps:
@@ -128,7 +370,7 @@ The initrd package would also have a "bootsplash" USE flag (on x86, maybe others) that would build in bootsplash support. Any non-default actions desired by the user can be handled with the utility from Stage 1. -
This would lead us to several case scenarios (assuming kernel-config is part of the base +
This would lead us to several case scenarios (assuming kernel-config is part of the base system):
@@ -138,13 +380,13 @@
default kernel, bootsplash initrd: "USE=bootsplash emerge mm-kernel initrd"
- non-default kernel, no initrd: "kernel-config gentoo-dev-kernel"
- non-default kernel, initrd: "kernel-config alpha-kernel"
- @@ -155,8 +397,8 @@
"emerge alpha-kernel initrd"
There are many advantages gained by this method:
@@ -173,27 +415,28 @@ portage and genkernel. Having competing build systems is not a GoodThing TM. Therefore, we can either make portage build kernels or we can make genkernel build everything else.
If you want to emerge kernel sources the old way, just do: USE="-buildkernel" emerge kernel-name-
Perhaps we could also name the new kernel-config program (from Stage 1) "genkernel" so that users +
Perhaps we could also name the new kernel-config program (from Stage 1) "genkernel" so that users can have a seemless transition.