Provided by: kernel-package_12.036+nmu3_all 
NOM
make-kpkg - Construction de paquets Debian du noyau à partir des sources du noyau Linux
SYNOPSIS
make-kpkg [options] [cible [cible ...]]
DESCRIPTION
Cette page de manuel décrit l'utilitaire Debian make-kpkg, utilisé pour créer les paquets
Debian concernant le noyau. Cet utilitaire doit être lancé à partir du répertoire racine
des sources du noyau Linux, noyau qui doit avoir été préalablement configuré (à moins que
vous n'utilisiez la cible « configure »). Normalement, si kernel-package ne trouve pas de
fichier .config dans le répertoire courant, il essaye absolument d'en trouver un autre qui
fera l'affaire (en fait, un fichier de configuration déjà pré-réglé pour les noyaux Debian
sur cette architecture) puis lancera un make oldconfig pour permettre à l'utilisateur de
répondre à toute nouvelle question. Typiquement, vous exécutez cette commande en tant que
root ou avec fakeroot, ou encore en indiquant à make-kpkg comment devenir root, comme
ceci :
make-kpkg --rootcmd fakeroot kernel_image
Le paquet Debian sera créé dans le répertoire père des sources du noyau depuis lequel la
commande a été lancée.
De plus, sachez que certaines versions de gcc ne fonctionnent pas très bien avec les
sources du noyau (gcc 2.95 rencontre des problèmes de compilation du noyau si on n'utilise
pas l'option de compilation « -fno-strict-aliasing »). Ce problème a été réglé pour les
noyaux récents (les séries 2.2 et 2.4 n'ont pas ce problème) (je crois que, pour les
noyaux plus anciens, vous risquez d'avoir à modifier le Makefile). Vous pouvez indiquer la
version de gcc à utiliser pour la compilation du noyau en définissant les variables CC et
HOSTCC du Makefile (le Makefile du premier niveau). Cela se fait tout simplement en
définissant la variable d'environnement MAKEFLAGS. Pour voir, essayez :
% KBUILD_VERBOSE=1 MAKEFLAGS="CC=gcc-4.4" make-kpkg configure
KBUILD_VERBOSE affiche le détail des commandes qui sont lancées (consultez le Makefile de
premier niveau afin de connaître les variables qui peuvent être définies).
Attention : Ne définissez pas l'option -j directement dans MAKEFLAGS, cela risque de faire
échouer la construction. Utilisez CONCURRENCY_LEVEL comme défini plus haut. L'option -j
peut aussi être utilisée.
OPTIONS
--help Afficher un message d'aide.
--revision numéro
Modifier le numéro de version pour les paquets construits par celui donné par
l'argument numéro. Cela impose plusieurs contraintes : la version ne doit contenir
que des caractères alphanumériques ou les caractères ~ + . (tilde, plus et point)
et doit contenir un chiffre (Consultez le manuel Policy pour plus de détails). Vous
pouvez éventuellement préfixer le numéro de modification par un chiffre suivi d'un
deux points (:). La valeur par défaut est 10.00.Custom à moins que la variable
d'environnement DEBIAN_REVISION_MANDATORY ne soit définie, auquel cas une erreur
sera produite si la modification n'est pas indiquée sur la ligne de commande ou
dans le fichier de configuration. Conseil : Vous pouvez le configurer à
$(version)-<truc> dans le fichier de configuration pour que le numéro de version
amont précède la chaîne personnalisée <truc>.
--append-to-version toto
--append_to_version toto
L'argument toto est ajouté à la valeur de la variable EXTRAVERSION présente dans le
Makefile du noyau. Puisque EXTRAVERSION fait partie de la version du noyau, il est
aussi ajouté au nom du paquet, et de ce fait doit obéir à la politique qui régit
les noms de paquet. Ce qui signifie qu'il ne doit contenir que des caracactères
alphanumérique en minuscules et des caractères ~ - + . (tilde, point, tiret et
plus). Les majuscules sont interdites selon la Charte pour les nouveaux paquets. Si
la variable d'environnement IGNORE_UPPERCASE_VERSION est définie, make-kpkg
changera la casse en minuscules pour le numéro de version défini soit dans le
Makefile ou dans le fichier localversion. Cette option outrepasse la variable
d'environnement APPEND_TO_VERSION.
--added-modules toto
--added_modules toto
Cet argument se présente sous la forme d'une liste de modules additionnels séparés
par des virgules (modules non inclus dans l'arborescence principale du noyau) que
vous souhaitez construire lorsque vous invoquez les cibles modules_truc. Vous devez
indiquer le chemin complet des répertoires contenant les modules, ou simplement le
nom du module s'il peut être trouvé dans MODULE_LOC, qui pointe par défaut sur
/usr/src/modules. Le comportement par défaut compile tous les modules qui sont dans
MODULE_LOC, quand les cibles modules_truc sont demandées.
--arch truc
Pratique pour définir l'architecture quand vous utilisez la compilation croisée. Si
vous ne faites pas de compilation croisée, l'architecture est automatiquement
déterminée. On peut obtenir le même résultat en réglant la variable d'environnement
KPKG_ARCH. Cette valeur doit correspondre au contenu de DEB_HOST_ARCH_CPU lorsque
dpkg-architecture est exécuté sur la machine cible, et elle peut correspondre à une
autre architecture dans le cas d'un ensemble multiarchitecture (comme i386/amd64).
--cross-compile truc
--cross_compile truc
Pratique pour définir la chaîne cible quand vous faites de la compilation croisée.
Utilisez la cible fantôme « - » si vous construisez pour les autres architectures
dans le cas d'un ensemble multiarchitecture, comme i386/amd64. Le même résultat
peut être obtenu en définissant la variable d'environnement. Notez bien que cela ne
règle en aucune manière le compilateur que le processus de construction du noyau
doit utiliser. Si le compilateur par défaut utilisé par le processus de
construction n'est pas celui dont vous avez besoin, définissez explicitement le
compilateur qui doit être utilisé. CROSS_COMPILE.
--subarch truc
Certaines architectures (comme Alpha, ou m68k) ont besoin de noyaux différents pour
chacune des sous-architectures. Cette option offre un moyen de le spécifier en tant
qu'argument de make-kpkg. Notez bien qu'une gestion de ces sous-architectures doit
être présente dans les sources du noyau afin que cette option serve à quelque
chose. On peut obtenir le même résultat en réglant la variable d'environnement
KPKG_SUBARCH.
--arch-in-name
--arch_in_name
Cette option rallonge le nom du paquet de l'image du noyau en intégrant la
sous-architecture dans le nom de l'image ; ainsi on peut écrire des scripts pour
créer de multiples sous-architectures, l'une après l'autre. On peut faire la même
chose en réglant la variable d'environnement ARCH_IN_NAME. Notez bien que seul le
nom du paquet est changé, pas l'emplacement des modules, etc.
--pgpsign nom
Définir la chaîne utilisée pour signer le fichier des modifications (changes) pour
les modules externes rangés dans /usr/src/modules/ et qui utilisent PGP. Cette
option prendra le pas sur le comportement par défaut et sur les préférences
générales qui se trouvent dans le fichier /etc/kernel-pkg.conf ou
~/.kernel-pkg.conf.
--config cible
Modifier le type de configuration utilisée, par défaut oldconfig. cible doit
prendre une des valeurs suivantes : oldconfig, config, menuconfig, gconfig,
xconfig, randconfig, defconfig, allmodconfig, allyesconfig, allnoconfig, old, menu,
g ou x.
Remarquez cependant que make-kpkg explore au démarrage le fichier de configuration
à la recherche de certaines options, notamment l'activation ou non des modules, et
que la modification de ce choix pendant la configuration engendrera une erreur. Si
nécessaire, créez un fichier de configuration le plus proche possible de celui
désiré avant d'appeler make-kpkg avec cette option.
--targets
Afficher la liste des cibles connues. Voir la section CIBLES ci-dessous.
--noexec
Passer l'option -n au processus make afin que les commandes soient simplement
affichées à l'écran mais pas réellement exécutées. C'est très pratique pour le
débogage.
--verbose
Appeler make avec l'option -V=1, ce qui appelle les commandes Make du niveau
supérieur, pratique pour voir ce qui est en train de se passer.
--initrd
Lorsque make-kpkg fabrique un paquet kernel-image, il prend ses dispositions pour
transmettre aux scripts hook lancés par les scripts de fin d'installation que cette
image a besoin d'un initrd, et que les scripts hook de création d'initrd ne doivent
pas être court-circuités avant. Sans cette option, le script hook initramfs fourni
en exemple avec kernel-package n'aura aucun effet lors de l'installation. Le même
résultat peut être obtenu en définissant la variable d'environnement INITRD avec
n'importe quel contenu. Notez bien qu'à moins qu'il n'y ait des scripts hook dans
/etc/kernel ou indiqués dans le paramètre hook script de /etc/kernel-img.conf,
aucun initrd ne sera créé (les scripts fournis ne sont que des exemples).
--jobs numéro
-j numéro
Configurer la variable d'environnement CONCURRENCY_LEVEL à numéro.
--overlay-dir /chemin/vers/répertoire
Le répertoire indiqué doit contenir les fichiers qui seront copiés dans le
répertoire ./debian des sources du noyau, afin de construire les paquets debian.
Les fichiers remplaceront tout ou partie du contenu de /usr/share/kernel-package
qui y serait normalement placé, et il est à la charge de l'utilisateur de vérifier
que les fichiers du répertoire indiqués sont compatible avec make-kpkg. Si
make-kpkg est cassé par un de ces fichiers, vous pouvez garder les morceaux. Le
même résultat peut être obtenu en définissant la variable d'environnement
KPKG_OVERLAY_DIR.
Veuillez noter que overlay-dir/Control et overlay-dir/changelog sont particuliers,
et que des substitutions de variables sont exécutées sur ces fichiers. Utilisez ces
fichiers /usr/share/kernel-package/Control et /usr/share/kernel-package/changelog
en tant que modèles (templates).
Si un programme (ou un script exécutable) overlay-dir/post-install est présent, il
sera exécuté immédiatement après le remplissage de ./debian. Le script sera exécuté
dans le répertoire ./debian. Cela peut servir par exemple à supprimer des fichiers
dont l'utilisateur n'a pas besoin, ou exécuter des opérations autres qu'un simple
remplacement.
--zimage
Créer un noyau en zImage plutôt qu'en bzImage (comportement par défaut). C'est
utile en cas de problèmes avec les noyaux bzImage.
--bzimage
Créer un noyau en bzImage. C'est utile pour avoir un noyau bzImage sur les systèmes
où le réglage par défaut est zImage.
--rootcmd commande
La commande qui offre la possibilité d'obtenir l'accès superutilisateur (par
exemple, « sudo » ou « fakeroot ») pour les besoins de l'option -r de
dpkg-buildpackage. Cette option ne fonctionne pas pour trois cibles précises, qui
sont binary, binary-indep et binary-arch. Pour ces cibles, la commande make-kpkg
doit être lancée en tant que root (ou fakeroot).
--stem truc
Appeler le paquet truc-* à la place de kernel-*. Pratique pour assurer la
transition du nommage des paquets de kernel-* à linux-*, afin de préparer les
noyaux non-linux de la distribution. Défini à linux par défaut. Cette chaîne,
puisqu'elle est le début du nom du paquet, ne doit comporter que des lettres
minuscules (a-z), des chiffres (0-9), plus (+), moins (-) ou des points (.). Elle
doit faire une longueur d'au moins 2 caractères, et commencer par une lettre.
--us Cette option est transmise à dpkg-buildpackage et demande de ne pas signer la
source. Elle n'a de sens que pour la cible buildpackage.
--uc Cette option est transmise à dpkg-buildpackage, et demande de ne pas signer le
changelog. Elle n'a de sens que pour la cible buildpackage.
Les options peuvent être raccourcies en la plus petite chaîne de caractères non équivoque
et peuvent être invoquées indifféremment avec les préfixes - ou -- ; Vous pouvez mettre un
espace ou un symbole = entre une option et sa valeur. Vous pouvez aussi utiliser la forme
option=valeur ; pour plus d'informations sur ces variantes et d'autres qui sont reconnues,
consultez la page de manuel Getopt::Long(3perl).
CONCURRENCY_LEVEL
Si elle est définie, cette variable d'environnement règle le nombre de processus
concurrents qu'utilisera make pour compiler le noyau et les modules, grâce à
l'option -j de la commande make lancée par la cible build de make-kpkg. Elle doit
être, si définie, un (petit) entier. Le nombre de CPU actuellement disponibles peut
être obtenu avec la commande :
grep -c '^processor' /proc/cpuinfo
Attention : Ne définissez pas l'option -j directement dans MAKEFLAGS, cela risque
de faire échouer la construction. L'option -j peut aussi être utilisée comme
argument de make-kpkg.
CIBLES
clean Cette cible efface tous les fichiers créés dans le répertoire des sources du noyau
par la cible build, et lance un make distclean (consultez le Makefile du noyau
Linux pour plus d'informations). Veuillez remarquer que malgré l'attention portée
aux réglages du noyau actuel, contenus dans le fichier .config, le fichier
include/linux/autoconf.h ne sera pas gardé. Cette cible ne doit pas être combinée
avec une autre, puisque make-kpkg lit toutes les données avant de lancer une
quelconque cible, donc les autres cibles seront exécutées avec les anciennes
données, ce qui n'est pas forcément ce que vous désirez.
buildpackage
Cette cible lance les cibles clean, et binary, et génère le paquet complet grâce à
dpkg-buildpackage.
binary Cette cible génère les quatre paquets Debian en lançant les cibles binary-indep et
binary-arch. Toutefois, il faut lancer make-kpkg en tant que root (ou fakeroot),
car --rootcmd ne fonctionnera pas.
binary-indep
Cette cible génère les paquets indépendants de l'architecture en lançant les cibles
kernel_source, kernel_manual et kernel_doc. Toutefois, il faut lancer make-kpkg en
tant que root (ou fakeroot), car --rootcmd ne fonctionnera pas.
binary-arch
Cette cible génère les paquets dépendants de l'architecture en lançant les cibles
kernel_headers et kernel_image. Toutefois, il faut lancer make-kpkg en tant que
root (ou fakeroot), car --rootcmd ne fonctionnera pas.
kernel_source
Cette cible génère un paquet Debian des sources du noyau Linux. Si la variable
d'environnement SOURCE_CLEAN_HOOK pointe sur un exécutable, alors cet exécutable
sera lancé, juste avant de faire le paquet, sur le répertoire (racine) temporaire
des sources du noyau, ./debian/tmp-source/usr/src/kernel-source-X.X.XX, de façon à
ce qu'on puisse lancer toute commande appropriée (supprimer des arborescences liées
à des architectures, ôter les répertoires de contrôle de version, find . -type d
-name CVS -prune -exec rm -rf {} \;, etc.) Cela ne concerne que les sources du
noyau qui sont en cours d'empaquetage. Si cette action porte sur le répertoire
courant et ses répertoires fils, l'arborescence originale qui contient les sources
reste, elle, inchangée. Les variables d'environnement HEADER_CLEAN_HOOK et
DOC_CLEAN_HOOK sont semblables. Elles doivent pointer sur des exécutables ; ces
exécutables seront appliqués sur le répertoire (racine) temporaire des en-têtes du
noyau et de la documentation juste avant la génération des paquets respectifs, de
façon à ce que vous puissiez lancer toute action qui vous semble adéquate. De même,
ne sont touchées que les sources qui sont en cours d'empaquetage.
kernel_debug
Cette cible fabrique une paquet Debian contenant les symboles de debogages pour les
modules contenu dans le paquet image correspondant. L'idée de base ici est de
garder le contrôle sur l'encombrement dans /lib/modules/<kver>, puisqu'il pourrait
s'agir d'une partition racine dotée de limites de taille.
kernel_headers
Cette cible crée le paquet Debian des fichiers d'en-têtes contenus dans le noyau
Linux.
kernel_manual
Cette cible génère le paquet Debian contenant les pages de manuel de la section 9
fournies dans le noyau Linux. Notez bien que ce n'est pas vraiment une cible
indépendante, puisque son appel déclenchera l'appel de la cible kernel_doc, et
créera un paquet kernel-doc en même temps.
kernel_doc
Cette cible génère un paquet Debian contenant la documentation contenue dans le
noyau Linux. Elle peut être appelée indépendamment de la cible kernel_manual, mais
l'inverse n'est pas possible.
kernel_image
Cette cible génère un paquet Debian contenant un noyau Linux, et tous les modules
définis dans le fichier de configuration du noyau .config. S'il n'y a pas de
fichier .config dans les répertoires des sources du noyau, une configuration par
défaut est utilisée, identique à celle utilisée pour créer les disquettes de
démarrage Debian.
Si le fichier ./debian/post-install existe, et qu'il s'agit d'un exécutable, il est
lancé juste avant la création du paquet de l'image du noyau. De même, notez que si
des scripts existent dans le répertoire ./debian/image.d/ , run-parts sera lancé
sur ce répertoire juste avant la création du paquet de l'image du noyau.
L'emplacement de la racine de l'image pour le paquet en cours de construction peut
être défini par la variable d'environnement IMAGE_TOP, et la version du noyau est
définie grâce à la variable d'environnement version pour tous ces scripts.
Consultez la documentation à propos des variables de type « hook » (points
d'entrée) dans kernel-img.conf(5). Ces variables peuvent indiquer des scripts qui
ajoutent ou suppriment une ligne dans le menu du grub à l'installation ou à la
suppression de l'image du noyau. Un exemple de script pour ajouter des lignes au
menu du grub est fourni dans le répertoire /usr/share/doc/kernel-package/.
En dehors de ces variables de type « hook » que l'administrateur peut définir, il
existe un ensemble de répertoires dans lesquels des paquets, ou l'administrateur,
peuvent déposer des scripts. Ces répertoires sont /etc/kernel/preinst.d/,
/etc/kernel/postinst.d/, /etc/kernel/prerm.d/, /etc/kernel/postrm.d/ et
/etc/kernel/preinst.d/<VERSION>/, /etc/kernel/postinst.d/<VERSION>/,
/etc/kernel/prerm.d/<VERSION>/ et /etc/kernel/postrm.d/<VERSION>/. Si ces
répertoires existent, le paquet kernel-image lancera le programme run-parts sur
ceux-ci, en passant en argument la version en cours d'installation ou de
suppression, durant la phase correspondante (installation ou suppression). Avant
d'appeler ces scripts, la variable d'environnement STEM doit être réglée avec le
contenu de l'argument --stem (ou à sa valeur par défaut, linux), et la variable
KERNEL_PACKAGE_VERSION doit contenir la version de kernel-package qui a créé ce
paquet. Ces scripts peuvent être appelés avec deux arguments, le premier étant la
version de l'image du noyau, et le second étant l'endroit où est rangé l'image
proprement dite. Lorsque debconf est lancé avant que le script ne soit appelé, ce
dernier ne devra pas générer de message de diagnostic sur la sortie standard — en
effet, au moment où la post-installation appelle db_stop, debconf ne rétablit pas
la sortie standard, tous les messages en sa direction disparaissent.
À l'installation, vous aurez la possibilité de lancer le chargeur de démarrage LILO
(ou des équivalents tels que loadlin, SILO, QUIK, VMELILO, ZIPL, yaboot, PALO ou
GRUB), en créant un fichier de configuration pour ces programmes de démarrage, si
nécessaire. À ce moment, vous aurez aussi la possibilité de mettre ce nouveau noyau
sur une disquette, en formatant la disquette si nécessaire. En cas de suppression,
le paquet vérifie la version du noyau en cours d'exécution, et refuse alors
d'effacer le noyau en cours d'utilisation. GRUB mérite une mention particulière
ici, puisque GRUB n'a pas besoin d'être relancé après l'installation d'une image de
noyau, et qu'une modification automatisée du contenu du menu est suffisante pour
l'installation ou la suppression d'une image d'un noyau.
build Cette cible, utilisée par la cible kernel_image ci-dessus, compile le noyau Linux.
modules
Cette cible permet de créer tous les modules et paquets additionnels qui dépendent
fortement de la version du noyau pour laquelle ils ont été compilés, en même temps
que vous construisez votre image du noyau. Cette cible s'attend à trouver les
modules et paquets sous /usr/src/modules, et, pour chacun de ces répertoires, se
déplacera dans MODULE_LOC/x (MODULE_LOC étant par défaut /usr/src/modules), et
lancera la règle kdist du fichier debian.rules qui s'y trouve. Cette cible créera
le ou les paquets Debian du ou des modules, ainsi qu'un fichier tar compressé et un
fichier diff compressé, les md5sums correspondants, créés par dpkg-genchanges,
seront enregistrés dans un fichier des modifications (changes). Ce fichier sera
signé avec la même identité que celle utilisée pour signer le paquet du noyau.
Cette option est utilisée par les responsables qui déploient les paquets dans les
archives de Debian.
modules_config
Cette cible permet de configurer tous les paquets de MODULE_LOC qui pointent par
défaut sur /usr/src/modules. À utiliser si vous avez besoin de modifier
manuellement certains points de la configuration, ou si vous voulez compiler
manuellement tous les modules additionnels. À n'utiliser que si vous disposez déjà
d'un répertoire ./debian.
modules_image
Cette cible permet de construire tous les paquets de MODULE_LOC qui pointent par
défaut sur /usr/src/modules, mais elle ne crée pas les fichiers sources ou diffs,
ni ne crée ni ne signe un fichier des modifications (un fichier « changes »). C'est
la seule option liée aux modules dont vous aurez besoin si vous voulez juste
compiler les modules additionnels pour leur installation sur une ou plusieurs
machines. Utilisée en général en conjonction avec kernel_image, notamment si vous
invoquez aussi l'option append_to_version (afin d'éviter de faux messages
d'avertissement). À n'utiliser que si vous disposez déjà d'un répertoire ./debian.
modules_clean
Cette cible permet de nettoyer tous les paquets de MODULE_LOC qui pointent par
défaut sur /usr/src/modules, ce qui devrait être suffisant pour défaire tout ce
qu'ont pu faire toutes les autres cibles modules_truc. À n'utiliser que si vous
disposez déjà d'un répertoire ./debian.
configure
Cette cible lance configure (en fait config_target, défini par --config qui pointe
par défaut sur oldconfig) assez tôt, de sorte que vous puissiez éditer les fichiers
créés par make config dans le répertoire des sources du noyau, sans que make-kpkg
ne les écrase ensuite.
debian Cette cible crée le répertoire ./debian et patche éventuellement le source. Cette
cible est appelée par la cible configure. Vous utiliserez cette cible pour corriger
les sources, puis vous lancerez l'étape de configuration manuellement afin de
mettre à jour le fichier de configuration avec toutes les nouvelles options de
configuration que les patches pourraient avoir ajoutées.
libc-kheaders
C'est une cible spéciale pour les responsables de libc-dev, qui peuvent s'en servir
pour créer les paquets d'en-têtes dont la libc a besoin. Notez qu'il est dangereux
de créer un paquet de libc-kheaders d'en-têtes différentes de celles avec
lesquelles la libc a été compilée. C'est une cause connue d'arrêts brutaux du
système. Consultez /usr/share/kernel-package/README.headers pour plus
d'informations. Créer et installer votre propre paquet libc-kheaders peut
endommager votre système, à moins que vous ne soyez sûr de ce vous faites. Vous
êtes prévenus.
VARIABLES D'ENVIRONNEMENT
KPKG_DEBUG, s'il est défini, demande à make-kpkg de cracher des messages de mise au point
(debug) concernant des fonctions du shell exécutées en interne. Cela n'intéressera
probablement personne, à part ceux qui mettent au point make-kpkg. Les variables suivantes
(décrites plus haut) affectent make-kpkg : DEBIAN_REVISION_MANDATORY, APPEND_TO_VERSION,
VERSION_H_OK, KPKG_ARCH, CROSS_COMPILE, KPKG_SUBARCH, KPKG_OVERLAY_DIR, ARCH_IN_NAME,
INITRD, SOURCE_CLEAN_HOOK, MODULE_LOC, CONCURRENCY_LEVEL et IGNORE_UPPERCASE_VERSION.
FICHIERS
Outre les options de lancement, le fichier debian.rules lancé par make-kpkg recherche
également un fichier de configuration propre à l'utilisateur ~/.kernel-pkg.conf. En cas
d'absence de ce fichier, il recherche un réglage par défaut pour tout le système dans le
fichier /etc/kernel-pkg.conf. La configuration par défaut permet le remplacement pour tout
le système du nom complet et du courriel de la personne responsable de la maintenance des
paquets du noyau sur le site, mais les fichiers /etc/kernel-pkg.conf (ou
~/.kernel-pkg.conf) sont en fait des bribes de Makefile, et toute directive valide peut y
être incluse. Remarque : la prudence est de mise avec ce fichier, puisque vous pouvez
changer complètement le comportement du make en modifiant son contenu. Consultez le
fichier /usr/share/doc/kernel-package/Problems.gz pour connaître la liste des problèmes
recensés lors de la compilation des images du noyau. Un tutoriel exhaustif et une
documentation sont aussi disponibles dans /usr/share/doc/kernel-package/README.gz et leurs
lectures sont recommandées avant l'utilisation de cet utilitaire.
VOIR AUSSI
dpkg-deb(1), dpkg-source(1), make(1), Getopt::Long(3perl), kernel-img.conf(5),
kernel-pkg.conf(5), le manuel des Programmeurs, le manuel de make du GNU et la
documentation complète du répertoire /usr/share/doc/kernel-package.
AUTEUR
Cette page a été écrite par Manoj Srivastava, <srivasta@debian.org>, pour le système
Debian GNU/Linux.