Content-type: text/html
Man page of MAKE-KPKG
MAKE-KPKG
Section: Manuel Debian GNU/Linux (1)
Updated: 14 nov. 2002
Index
Return to Main Contents
NOM
make-kpkg - construit des 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, 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 parent 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 l'option de compilation « -fno-strict-aliasing ») n'est pas
utilisée. Ce problème a été réglé pour les noyaux récents (les séries 2.2 et
2.4) (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 grâce à :
% MAKEFLAGS="CC=gcc-2.95" make-kpkg ...
(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 loin.
OPTIONS
--help affiche un message d'aide.
- --revision numéro
-
Modifie le numéro de révision Debian des paquets créés avec ce numéro. Il
y a quelques contraintes d'utilisation : l'option --revision n'a d'effets
que pendant la phase de configuration. En d'autres termes, si le fichier
stamp-configure existe, cette option n'aura pas d'effet. Exécutez
b<make-kpkg clean> ou supprimez vous-même stamp-configure et
stamp-debian afin que l'option fonctionne. Il est recommandé avec
insistance d'utiliser make-kpkg clean sauf si vous êtes sûr de ce que
vous faites. De plus, les responsables officiels des paquets des sources
fournissent leurs propres numéros de versions et données pour leurs envois
officiels dans l'archive Debian, ce qui entraîne qu'un certain nombre de
choses, dont le numéro de révision Debian, ne seront pas modifiées par
make-kpkg. S'il vous arrive d'avoir une source officielle, (il y a alors
un fichier debian/official qui ne doit pas être vide), et que vous voulez
utiliser votre propre numéro de révision, pensez bien à supprimer
debian/official avant de lancer make-kpkg clean si vous voulez que cette
option fasse effet. Par conséquent, si vous voulez relancer make-kpkg
avec un numéro de révision différent, assurez-vous de commencer avec une
structure propre. Ensuite, le numéro de version doit être composé uniquement
de caractères alphanumériques, des caractères + et . (plus et point), et
doit impérativement comporter un chiffre (consultez la charte Debian pour
plus d'informations). En fait, c'est un mensonge. Les responsables
officiels du noyau et des modules ont une dispense spéciale qui leur permet
l'usage du trait d'union, mais cela est fortement déconseillé à la plupart
des gens, puisqu'aucune correction du numéro de version n'est faite, et dpkg
et autres risquent de planter en fin de compilation sans qu'il soit possible
de déterminer précisément d'où cela vient. Enfin, vous pouvez préfixer la
version d'un chiffre suivi de deux points (:). La valeur par défaut est
10.0.0.Custom à moins que la variable d'environnement
DEBIAN_REVISION_MANDATORY ne soit activée, auquel cas une erreur est
générée si le numéro de version est omis dans la ligne de commande ou le
fichier de configuration.
- --append-to-version toto
-
- --append_to_version toto
-
Cet argument (toto) est ajouté à la valeur de la variable EXTRAVERSION du
Makefile du noyau. Puisque EXTRAVERSION est un des composants du numéro de
version du noyau, il est aussi ajouté au nom du paquet Debian, et en tant
que tel, doit répondre aux contraintes de la charte concernant les noms de
paquets. Ce qui veut dire qu'il ne doit contenir que des caractères
alphanumériques minuscules et les caractères -, + et . (moins, plus et
point). Les lettres majuscules ne sont pas autorisées par la Charte pour un
nouveau paquet. Si la variable d'environnement IGNORE_UPPERCASE_VERSION
est définie, make-kpkg écrira le numéro de version défini dans le Makefile
ou dans le fichier localversion en minuscules. Cet argument est
prioritaire sur la variable d'environnement APPEND_TO_VERSION. Notez bien
que vous devez lancer make-kpkg clean après avoir configuré
le noyau avec make (x|menu)?config, puisque celui-ci génère le fichier
include/linux/version.h sans la valeur append_to_version (toto). Ce
fichier ne sera pas modifié par le lancement de make-kpkg (make-kpkg crée
version.h s'il n'existe pas, mais ne le modifie pas s'il existe), et donc le
noyau final n'aura pas la valeur append_to_version dans son numéro de
version, et ira chercher les modules et les symboles aux mauvais
endroits. Le plus simple est soit de supprimer include/linux/version.h après
la configuration et avant la compilation, soit de lancer make-kpkg clean
après la configuration, et avant la compilation. Notez aussi qu'une fois que
vous avez utilisé --append_to_version toto pour la configuration ou la
construction du kernel-image, vous devez aussi utiliser la même option lors
de lancements ultérieurs de make-kpkg (par exemple, pour construire des
modules indépendants, ou autres). make-kpkg ne se souvient pas de l'argument
toto à chacun des lancements de la commande (ce comportement est différent
de --revision, qui est lui persistant lors des différents lancements). Si
vous en avez assez de voir make-kpkg se plaindre de l'utilisation de
--append_to_version alors qu'il y a déjà un fichier créé précédemment, vous
pouvez définir la variable d'environnement VERSION_H_OK, ce qui fera cesser
cet avertissement.
- --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.
- --added-patches truc
-
- --added_patches truc
-
Cet argument (truc) doit être une liste de patches additionnels pour les
sources du noyau séparés par des virgules. L'option de configuration
patch_the_kernel sera alors automatiquement réglée à « YES ».
-
Contrairement à la gestion des modules, vous pouvez n'indiquer que le nom du
fichier de patch (et pas le chemin complet du fichier). De plus, tout patch
qui essaye de modifier le numéro de version, que ce soit par l'édition du
Makefile, ou par l'ajout d'un fichier .localversion, ne fonctionnera
pas, et interrompera la compilation, puisqu'un numéro de version a déjà été
défini dans debian/changelog.
-
Pour chaque fichier <nom_patch> de la liste, l'algorithme suivant
est appliqué : si ce fichier est trouvé dans les répertoires
ALL_PATCH_DIR/{apply,unpatch}/, alors le fichier
ALL_PATCH_DIR/apply/<nom_patch> sera appliqué pendant la phase de
configuration (on présume que cela appliquera le patch). De la même façon,
le fichier ALL_PATCH_DIR/unpatch/<nom_patch> sera exécuté pendant
la phase « clean ». Par défaut, tous les patches sont appliqués en lançant
tous les exécutables contenus dans ALL_PATCH_DIR/apply/ si la demande en
est faite (que ce soit par l'option de configuration patch_the_kernel ou
par la mise à YES de la variable d'environnement PATCH_THE_KERNEL. Notez
bien que les patches sont DÉSINSTALLÉS des sources quand vous lancez la
cible « clean ». Ce nettoyage peut être désactivé par la définition de la
variable d'environnement NO_UNPATCH_BY_DEFAULT.
-
Dans ce qui précède, ALL_PATCH_DIR pointe par défaut vers un
sous-répertoire de /usr/src/kernel-patches/.
-
Parfois, il serait pratique de voir les patches s'appliquer quand quelqu'un
demande un patch spécifique grâce à cette option, sans être obligé de
définir explicitement la variable d'environnement. Mais puisque régler la
variable d'environnement PATCH_THE_KERNEL à « YES » peut être dangereux
(dans le sens où tous les patches seraient installés quand vous n'en vouliez
aucun, puisque vous n'avez pas spécifié l'option added_patches), vous pouvez
régler la variable PATCH_THE_KERNEL à AUTO, et dans ce cas,
PATCH_THE_KERNEL sera réglé à « YES » quand vous demanderez
--added-patches truc, et pas dans le cas inverse. De plus, notez que si
un quelconque patch installe un script dans le répertoire
./debian/image.d/, run-parts sera lancé sur ce répertoire juste avant
la construction du paquet de l'image du noyau. L'emplacement de la racine du
paquet en cours de construction sera défini dans la variable d'environnement
IMAGE_TOP, et la version du noyau sera transmise par la variable
d'environnement version. C'est un des systèmes utilisés par le patch pour
insérer, par exemple, des fichiers supplémentaires dans l'image.
-
Certains des paquets de patches sont attentifs à d'autres variables
d'environnement, décrites dans le répertoire de documentation correspondant
(vous devriez par exemple consulter
/usr/share/doc/kernel-patch-truc/README-kernelpatch.Debian pour obtenir
des informations complémentaires sur le patch truc).
- --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. Le même résultat peut être obtenu 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 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
noyaux 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 des scripts peuvent être
écrits pour créer de multiples sous-architectures, l'une après l'autre. La
même chose peut être faite 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éfinit 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
-
Modifie le type de configuration utilisé, par défaut oldconfig. Cible
doit prendre l'une des valeurs suivantes : oldconfig, config,
menuconfig, gconfig, xconfig, randconfig, defconfig,
allmodconfig, allyesconfig, allnoconfig, old, menu,
g, ou x.
Cette option est particulièrement utile lors de l'utilisation de
PATCH_THE_KERNEL lorsque certains patches modifient les options de
configuration offertes. Notez 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 plus tard dans 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
-
Affiche la liste des cibles connues. Voir la section Cibles plus loin.
- --noexec
-
Passe 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
-
Appelle 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
-
Si make-kpkg génère un paquet kernel-image, déclenche toutes les
actions nécessaires lors du chargement d'un noyau utilisant
initrd. NOTE : Sur d'anciens noyaux, cela nécessite un patch non
standard des sources du noyau pour initrd et cramfs (à moins que la
configuration de mkinitrd n'ait été modifiée afin de ne pas utiliser
cramfs), sans lequel vous risquez d'obtenir un noyau non amorçable. Ce patch
est généralement présent dans les sources du noyau fournies par
Debian. Certaines architectures ont toujours besoin de patches pour corriger
les problèmes cramfs. Cette option peut entraîner des dépendances
additionnelles, et des modifications des scripts du responsable. Elle n'a
pas d'effet quand make-kpkg ne génère pas de paquet kernel-image. Le
même résultat peut être obtenu en donnant à la variable d'environnement
INITRD une valeur non vide.
- --zimage
-
Génère un noyau en zImage plutôt qu'en bzImage (comportement par
défaut). C'est utile pour ceux qui ont des problèmes avec les noyaux
bzImage.
- --bzimage
-
Génère un noyau en bzImage. C'est utile pour ceux qui veulent un noyau
bzImage sur les systèmes où le réglage par défaut est zImage.
- --mkimage
-
La valeur sera une commande pour créer une image initrd, un répertoire
étant donné. Elle est passée à l'option -m du programme mkinitrd.
Par exemple,
"genromfs -d %s -f %s"
ou
"mkcramfs %s %s"
- --rootcmd commande
-
La commande qui offre la possibilité d'obtenir l'accès superutilisateur (par
exemple, « sudo » ou « fakeroot »). Cet accès est nécessaire pour
l'option -r de dpkg-buildpackage.
- --stem truc
-
Nomme 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. La valeur par défaut est linux.
- --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 niveau de
profondeur (NdT : concurrency) utilisé par make pour compiler le noyau
et l'ensemble des modules. Elle utilise le drapeau -j dans le make qui
est dans la cible build de make-kpkg.
Elle doit être un (petit) entier, si vous la définissez. Vous pouvez
obtenir le nombre actuel de CPU grâce à la commande :
"grep -c '^processor' /proc/cpuinfo"
ATTENTION :
NE définissez PAS l'option dans MAKEFLAGS directement, cela entraînerait
l'échec de la construction.
CIBLES
- clean
-
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.) Notez que malgré l'attention portée
aux réglages du noyau courant 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 sûrement pas 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.
- 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.
- binary-arch
-
Cette cible génère les paquets dépendants de l'architecture en lançant les
cibles kernel_headers et kernel_image.
- 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 que toute
commande appropriée puisse être lancé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_headers
-
Cette cible génère 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.
-
Lors de l'installation initiale, le paquet image met à jour le lien
symbolique contenu dans le répertoire destination (la racine, par défaut)
afin qu'il pointe sur la nouvelle image du noyau dans le répertoire des
images, qui est /boot. Si le lien symbolique pointe déjà sur l'image du
noyau à jour, rien ne se passe. Si le lien pointe sur une version
précédente, il y a permutation avec le suffixe .old, et un nouveau lien
symbolique, correctement mis à jour, prend sa place (la variable
minimal_swap dans /etc/kernel-img.conf modifie ce comportement). Rien
n'est fait lors de mises à jour.
-
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>/,
/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 peut être réglée
avec le contenu de l'argument --stem (ou à sa valeur par défaut,
linux). 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. Puisque 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 vous permet de générer 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(s) paquet(s)
Debian de(s) module(s), ainsi qu'un fichier tar compressé et un fichier
diff compressé, les md5sums correspondants, généré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 vous 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. Elle est
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 vous 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 patcher les sources, puis vous lancerez l'étape de
configuration manuellement.
- 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 différent des en-têtes
avec lesquels 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 sortir des messages
de débogage concernant des fonctions du shell exécutées en interne. Cela
n'intéressera probablement personne, à part ceux qui déboguent
make-kpkg. Les variables suivantes (décrites plus haut) affectent
make-kpkg : DEBIAN_REVISION_MANDATORY APPEND_TO_VERSION
VERSION_H_OK PATCH_THE_KERNEL NO_UNPATCH_BY_DEFAULT KPKG_ARCH
CROSS_COMPILE KPKG_SUBARCH ARCH_IN_NAME INITRD
SOURCE_CLEAN_HOOK MODULE_LOC CONCURRENCY_LEVEL
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. Note : 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
kernel-pkg.conf(5), kernel-img.conf(5), mkinitrd(8),
Getopt::Long(3perl), dpkg-deb(1), dpkg-source(1), make(1), le
manuel des Programmeurs, le manuel du 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.
TRADUCTION
Cette page de manuel a été traduite et est maintenue par Sylvain Cherrier
<sylvain.cherrier@free.fr> et les membres de la liste
<debian-l10n-french@lists.debian.org> entre 2004 et 2007.
Index
- NOM
-
- SYNOPSIS
-
- DESCRIPTION
-
- OPTIONS
-
- CIBLES
-
- VARIABLES D'ENVIRONNEMENT
-
- FICHIERS
-
- VOIR AUSSI
-
- AUTEUR
-
- TRADUCTION
-
This document was created by
man2html,
using the manual pages.
Time: 12:37:45 GMT, March 12, 2007