Migrating to the common kernel-image package -------------------------------------------- Files for architecture should be placed into arch/. Minimally, this directory should contain a control.in, config.default and at least one flavour configuration file config.. It can optionally contain config.common, Makefile.inc and multiple flavour configuration files. For arches with subarches the subdirectory arch// 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 'patches' subdirectory of arch/ or arch//. This directory is expected to contain the patch files and a file 'list' with list of patches to apply. 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 . files, may be missing. For architecture without subarches: Configuration file for kernel-image: arch/config.common arch//config.common arch//config. Configuration file for kernel-headers: arch//config.default For architecture with subarches: arch/config.common arch//config.common arch///config.common arch///config. Configuration file for kernel-headers: arch///config.default It is possible to avoid the inclusion of the arch-independent config file (handy for the transitional period) by setting the include_common_config variable to 'no' in Makefile.inc. Debian and arch/subarch specific patches ----------------------------- This is not really settled yet. Ideally we would like to integrate all this stuff into the kernel-source package. So for now it is probably reasonable to assume that common-arch debian patches are going to be in debian/patches directory. As I understand, we will not need the kernel-tree stuff, as the source with patches is going to accompany each upload. So we might just place them there along with the list, which will determine the order of application. For unmerged arch/subarch specific patches we can do the same in the arch/subarch directory: patches/ subdir will contain patches and a list. Currently the kernel is patched using the kernel-source package only. 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 debian/control.in and all the control.in files found in and in subdirectories of arch/, and performing the variable substitution. Currently the following variables are going to be substituted: @karch@ Replaced by the architecture string, identical to DEB_HOST_ARCH, as returned by dpkg-architecture. @version@ Upstream kernel version, for example 2.6.11. @ktver@ Minor version of kernel-tree to build-depend on. @abiname@ Abiname value for this set of packages. @kbpkg@ Current name and version of the kernel-build package to build-depend on. Typical value may be 'kernel-build-2.6-3', for example. After variable substitution the resulting file is 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: include_common_config Setting it to 'no' (without quotes) will prevent the common kernel config from being included for this particular architecture. Typical usage: include_common_config := no 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. Typical usage: headers_extra := arch/i386/kernel/asm-offsets.s 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 added_patches Setting this variable to non-empty value will cause an option --added_patches to be added to the make-kpkg 'build' and 'kernel-image' calls. The value of the variable will be given as an argument for the --added-patchs option. The value of this variable may contain a special string @uver@ which is going to be expanded into the upstream kernel's version with dots replaced by underscores (for example, 2_6_11 for the kernel version 2.6.11). Typical usage: added_patches := debian,hppa-@uver@ 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. 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 Note that the value of this variable is ignored. 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//initrd directory, so that they will be included by mkinitrd. Full pathname relative to the /lib/modules/ 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