This is the Debian Linux packaging scripts for the Linux kernel. 
This package has been put together by Manoj Srivastava <srivasta@debian.org>.


INTALLATION NOTES:

To use this package to create kernel-image packages, you need to get
the kernel source (available from your favourite linux archive),
unpack your kernel somewhere. Preferably somewhere other than
/usr/src/linux (more on this later).

Before you go any further, please allow me to point out that you need to
have a few other packages installed before you can compile your own kernels
(it is difficult to compile anything without a compiler ;-). The packages
suggested are:
devel:        gcc, libc5-dev, binutils, make, and, for intel x86 platforms,
              bin86 (non-intel platforms don't need this).
interpreters: gawk.
base:         gzip, shellutils, and grep.

Of course, pretty gui frontends to kernel configuration require more
packages, but they are not strictly essential (though quite nice really). 


Unpacking kernel sources:
-------------------------

On a debian system, /usr/src/linux always either contains 
include/{linux,asm} or points to a directory which contains
those subdirectories, usually a directory with the full kernel
source or a directory with just the kernel headers.

Debian has standardized on /usr/src/linux being a link (that is the
case if you install released debian kernel packages, and has been
for a while now).

If you like living on the edge and compiling your own kernel 
packages ;-), you have to follow the convention of letting
/usr/src/linux be a link, and unpack the pristine kernel sources
someplace else.

Some of the suggestions about where to unpack the kernel packages are
a) /tmp/linux
b) /var/tmp/linux
c) /usr/src/linux-X.X.XX; where X.X.XX is the version numnber of the
   kernel. Remember to re-link /usr/src/linux to point to this
   directory, like: (cd /usr/src; rm linux; ln -s linux-X.X.XX) 

In any case, choose a partition that has a large amount of free space,
since recent kernels, unpacked, run to about 23MB, and you need more
than double that in order to create kernel-image, kernel-source, and
the tar file (that is, if you choose to build everything together with
the dist target in debian.rules -- say if you want, for whatever
reason, to run dchanges on the files created). I needed nearlt 60MB to
create the full spectrum of packages for version 1.99.7 (and doubtless
this size will go up in the future).

Now, cd linux (wherever you have created the kernel sources).

The version number is deduced from the kernel Makefile directly. to
ensure that the version numbers are in sync(1), so you don't have to
worry about that.

It has been suggested that you renumber the revision number in such a
way that a generic kernel image package will not override the custom
package while using dselect (or dpkg -BORGiE). You may do this on the
fly by setting the DEBIAN_REVISION environmental variable, or as an
argument to make-dpkg.

The revision number (the argument supplied after the --revision flag)
has certain constraints: it may contain only alphanumerics and the
characters + . (full stop, and plus) and should contain a digit.
NOTE: No hyphens allowed. (Look at Chapter 5 of the Programmers manual
for details)

This is because dpkg imposes an ordering on version numbers, so that
it can tell whether packages are being up or downgraded and so that
dselect can tell whether a package it finds available is newer than
the one installed on the system.

I've found that using a two-level scheme where the major level starts
with a letter nicely does the job, (--revision custom.Y, so the image
package become kernel-image-X.X.XX-custom.Y.deb), and dselect and dpkg
-BORGiE will refuse to downgrade to a generic kernel (don't give the
BGO arguments to dpkg if you actually do want to downgrade later).


You may also wish to change the maintainers name and email adress in
/etc/kernel-package.conf, to remind you that this is not an official
package, unless, of course, you happen to be the maintainer (Hi
Simon).  The file /etc/kernel-package.conf is actually a Makefile
snippet included during the kernel packages build process, and hence
you may put any legal Makefile directive in that file (just make very
sure you know what you are doing ;-).  

	At the moment, the user modifiable variables supported are:
maintainer:	Local kernel-* package maintainer
email:          The email address of that person.
pgp:            Name to search for in the pgp database _iff_ separate
                modules (like pcmcia etc) are being built in
                /usr/src/modules/*. Can be set from environment
                variable PGP_SIGNATURE. Defaults to maintainer.
debian:		The Debian revision of the kernel packages. Can be set
		from the environment variable DEBIAN_REVISION, defaults
		to 1.00.
image_in_boot:	Set to True if you want the kernel image symlink (vmlinuz)
                and System.map symlink in /boot rather than the default /. 
		Can be set from the environment variable IMAGE_IN_BOOT. 
		defaults to undefined.
kimage:		The kernel image type (i.e. zImage or bzImage). Can be
		set from the environment variable IMAGE_TYPE. Defaults
		to bzImage.

The value of a variable can be set so: 
  a) Defaults exist in the rules file. These are the values used if no
     customization is done.
  b) Variables can be set in the config file /etc/kernel-pkg.conf. 
     These values over ride the defaults.
  c) Variables can also be set by setting a corresponding envirnment
     variable.  These values over ride the config file and the defaults
  d) Using make-kpkg options, or, if using the rules file directly, on 
     command line ( # xxx/rules DEBIAN_REVISION=2.0a kernel_image). This 
     over rides all the above methods.

Please see kernel-pkg.conf (5).

To generate a new kernel image, just run
% make-kpkg clean
% make-kpkg -revision custom.1.0 kernel_image

This will create a default kernel image (as in the image package or
available on the boot disks.  The kernel image package produced will
offer you a chance to create a bootdisk, or to run lilo, but the
default is not to do either, and you may choose to ignore these
friendly overtures by the postinst.

If you want a custom kernel, you may generate a config file by any of
these methods (just follow the directions).
% make config          # Boring old tty based method
or
% make menuconfig      # curses based menu driven method (uses color if 
                         you have any)
% make xconfig         # An X window system based method -- make sure
                         you are running X windows when you call this.
All these methods ultimately generate a .config file.  If you already 
have a .config file, just copy it to this directory, and you are go.

With a custom .config file in place (created as above) run again:
% make-kpkg clean
% make-kpkg -revision custom.1.0 kernel_image

To create a source or header package, run
% make-kpkg clean
% make-kpkg -revision custom.1.0 kernel_source
% make-kpkg -revision custom.1.0 kernel_headers
Note: You only need one of these.

Or if you want to generate the whole package, 
% make-kpkg -revision custom.1.0 -signature "Your pgp id" dist
Note that this needs a pgp key.

A note on lilo: the kernel-image install-scripts arrange to have
/vmlinuz and /vmlinuz.old point to the latest kernel image and the
next most recent one, respectively.  You may choose to have lilo take
advantage of this by putting image = /vmlinuz and image = /vmlinuz.old
lines in your lilo.conf (please read documentation on lilo for
details)

Conversly, people who wish to tightly control the versions in
lilo.conf (believe me, people, this gets to be a pain in the neck
fast) can use image = /boot/vmlinuz-X.X.XX.

So that loadlin people don't feel left out, all this talk  about lilo
does not mean that loadlin folks are being left out in the cold, you
can use the generated kernel-image just as easily (simply ignore the
fol-de-rol with sym links in /). for instance, you
could: 

 [1]% dpkg -BRGiE kernel-image-X.X.XX,
        and then
 [2]% cp /boot/vmlinuz-X.X.XX <place where loadlin needs image>
 [3]% echo '' > /boot/vmlinuz-X.X.XX

        So you don't have the image taking upspace, but still leave a
target for the /vmlinuz symlink.

Have fun,

	Manoj Srivastava
-- 
Foot note 1:
  For an explanation on why this synchonization is required, consider
  this. The kernel knows what version it is, as given in the kernel
  Makefile as the variables VERSION, PATCHLEVEL, and SUBLEVEL. It will
  look for the modules in /lib/modules/$VERSION.$PATCHLEVEL.$SUBLEVEL.
  The debian scripts think they know what the kernel version is, as
  given in the debian file debian.rules as the variable v (near the
  top). It then proceeds to put the modules in /lib/modules/$v.  So,
  it is essential that the kernel (Makefile) and the debian script
  (debian.rules) agree about the version number, or the kernel will
  never figure out where the debian scripts hid the modules. So change
  the version number in the file debian.rules (v = X.X.XX) to be the
  same version as given in the kernel Makefile (this  will be
  $VERSION.$PATCHLEVEL.$SUBLEVEL).

Manoj Srivastava                        <srivasta@debian.org>
