--- 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 @@ --> - + GLEP 26 -- Handling kernels with portage - + -
- +
@@ -35,7 +277,7 @@ - + @@ -43,7 +285,7 @@ - + @@ -52,8 +294,8 @@
Version:1.2
Last-Modified:2004/11/11 21:32:21
Last-Modified:2004/11/11 21:32:21
Author:Nathaniel McCallum <npmccallum at gentoo.org>, Joshua Campbell <warpzero at gentoo.org>
Type:Standards Track
Content-Type:text/x-rst
Content-Type:text/x-rst
Created:2-May-2004

-
-

Contents

+
+

Contents

-
-

Abstract

+
+

Abstract

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.

-
-

Status

+
+

Status

Timed out

-
-

Motivation

+
+

Motivation

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.

-
-

Specification

+
+

Specification

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 @@
      1. default kernel, bootsplash initrd: "USE=bootsplash emerge mm-kernel initrd"

      2. -
      3. +
      4. non-default kernel, no initrd: "kernel-config gentoo-dev-kernel"

        "emerge gentoo-dev-kernel"

      5. -
      6. +
      7. non-default kernel, initrd: "kernel-config alpha-kernel"

        "emerge alpha-kernel initrd"

        @@ -155,8 +397,8 @@
-
-

Rationale

+
+

Rationale

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.

-
-

Backwards Compatibility

+
+

Backwards Compatibility

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.

-
-

Reference Implementation

+ - - +