Migrating to the common kernel-image package
--------------------------------------------
Files for architecture <arch> should be placed into arch/<arch>.
Minimally, this directory should contain a control.in, config.default
and at least one flavour configuration file config.<flavour>. It can
optionally contain config, Makefile.inc and multiple flavour
configuration files. For arches with subarches the subdirectory
arch/<arch>/<subarch> with the same file structure must be created
for each subarch.
Support for arch/subarch-specific patches
-----------------------------------------
Patches specific to a particular architecture or subarchitecture and
not included into the debian patch set should be placed in the
debian/patches-arch subdirectory. Patch must be named <arch>.diff or
<subarch>.diff. If such patch is present, it will be automatically
applied during the unpacking of the build tree for a particular
(sub)architecture. Patches present in the debian/patches-arch will also
be included in the kernel-patch-debian package, suitable for building
kernels with make-kpkg.
Config files
------------
Configuration files are constructed dynamically by concatenating a number
of config files as described below. Any of the files, except the .default
and lowest-level .<flavour> files, may be missing.
For architecture without subarches:
Configuration file for kernel-image:
arch/config
arch/<arch>/config
arch/<arch>/config.<flavour>
Configuration file for kernel-headers:
arch/<arch>/config.default
For architecture with subarches:
arch/config
arch/<arch>/config
arch/<arch>/<subarch>/config
arch/<arch>/<subarch>/config.<flavour>
Configuration file for kernel-headers:
arch/<arch>/<subarch>/config.default
Control file
------------
The master control file debian/control must be generated before
the package is uploaded. debian/rules contains the debian/control
target, which generates the control file by concatenating the
common templates for it and substituting the variables:
@version@ Upstream kernel version, for example 2.6.11.
@major@ The major version, for example 2.6
@arch@ The Debian arch name, such as powerpc or i386.
@subarch@ The subarch - only used by powerpc right now.
@flavour@ The build flavour, such as 686 or k7-smp.
@smpflavour@ Same as flavour, but turns k7-smp into "multiprocessor k7".
@shortsmpflavour@ Same as smpflavour, but turns k7-smp into "SMP k7".
@ltver@ linux-tree version, a single digit.
@srcver@ Source version, extracted from the changelog.
This is normally @version@-@ltver@.
@lt_depends@ The Depends field for the linux-tree package.
@lt_provides@ The Provides field for the linux-tree package.
@abiname@ Current abiname, a single digit.
@allheaders@ Given the arch, a list of all the linux-headers packages for the
arch - used for kernel-headers-x.y.z-n-arch.
For each kernel image build the control.source.in template from
templates directory is concatenated with the control.in file from the
arch/<arch> or arch/<arch>/<subarch> directory, and the following
variables are substituted: @version@, @ltver@, @major@, @abiname@.
A arch/subarch-specific control.in file should contain only entries
for binary linux-image-$(version)-$(abiname)-$(flavour) and
flavour-specific linux-headers-$(version)-$(abiname)-$(flavour)
packages. linux-headers-$(version)-$(abiname) package entry is
included automatically.
After variable substitution the resulting files are formatted to
ensure that the only blank lines are the ones separating the
entries (i.e. before the next Package: line).
Makefile.inc
------------
Each architecture subdirectory in arch may contain a Makefile.inc
file, which is included by debian/rules after definining all the
variables. It may be used to override the standard variables on
per-architecture basis and other evil things. So far the valid uses of
this file include the setting of the following variables:
headers_dirs
This variable is substituted into the headers-install script,
controlling which asm-* directories are included into the
kernel-headers package. By default it is set to karch (see
above). See header-install.in file for detail. Typical usage:
headers_dirs := sparc | sparc64
headers_extra
This variable is substituted into the headers-install script,
and may be used to specify extra files, which a particular
architecture would like to include in the kernel-headers package.
Files should be specified with a full path relative to the
top-level kernel directory, unquoted and separated by spaces.
Note that you normally do not need to specify the files
arch/$(karch)/kernel/asm-offsets.s, they are going to be included
automatically.
headers_subarch
The subarch to pass to the --subarch option for the make-kpkg
call to build the kernel-headers. Typical usage:
headers_subarch := sparc64
build_subarch
Setting this variable to non-empty value will cause an option
--subarch $(build_subarch) added to 'build' and 'kernel-image'
make-kpkg calls. If a substring @flavour@ is present in the
definition of this variable, it will be expanded to the current
flavour during build time. In general, if you wish to add subarch
support for your architecture, you should contact kernel-package
maintainer to ensure that the flavour name correctly maps onto a
kernel subarch name. Typical usage:
build_subarch := pmac
or
build_subarch := @flavour@
build_makeflags
This variable may contain the make flags settings for the
make-kpkg invocation in the 'build' target. Currently it is
only used by amd64, where it should be set to something like
build_makeflags := 'CC=amd64-linux-gcc V=1'
The value of the variable must be properly quoted.
initrd_modules
This variable may contain a space-separated list of modules
which should be hard-linked into the /lib/modules/<version>/initrd
directory, so that they will be included by mkinitrd. Full
pathname relative to the /lib/modules/<version> directory should
be give, no quoting is necessary. Typical usage:
initrd_modules := kernel/drivers/video/vesafb.ko kernel/security/capability.ko
image_postproc
A command to be run after the kernel image is built. As far as I know,
it only required on sparc for stripping of the kernel which is too big
to be booted otherwise. Typical use is too ugly to be presented here.
image_prefix_flavours
image_prefix
These variables allow to prepend the 'make-kpkg kernel_image' call with
an arbitrary prefix for selected flavours. Some architectures have a
32- and 64-bit versions. If kernels are built on the 64-bit hardware, then
building a 32-bit kernel usually requires using a wrapper which sets the
correct execution domain (such as sparc32 or linux32). If the variable
image_prefix_flavours is non-empty and contains a space-separated list
if flavours, then make-kpkg invocation to create a kernel_image target
will be prepended with contents of the image_prefix variable. Typical
usage:
image_prefix_flavours := sparc32 sparc32-smp
image_prefix := sparc32
default_config
This variable controls which kernel config file will be used as a
"default" config file, used when building the kernel-headers package.
It does not really matter which file is used, see the message at
http://lists.debian.org/debian-kernel/2004/08/msg01460.html
The following algorithm will be used to determine the default kernel
config file:
* If the default_config variable is defined, use config.$(default_config).
* If it is not defined and config.default exists, use that.
* If neither default_config is defined not config.default exists, pick
the first flavour from the flavour list and use its config.
Typical usage:
default_config := 386
extra_postinstall_command
This variable, if defined, is executed at the end of the post-install script,
which is used by kernel-package to add or modify the files going into the
kernel image package.
It can use these variables (but see templates/post-install.in for details) :
$(subarch), $(flavour), $(version) and $(abiname). Since Makefile.inc is a
Makefile, the leading $ need to be escaped as double $$.
2742fc1839