kernel-pkg.conf - fichier de configuration générale pour make-kpkg

/etc/kernel-pkg.conf ou ~/.kernel-pkg.conf

Le fichier /etc/kernel-pkg.conf ou ~/.kernel-pkg.conf est en fait un bout de Makefile inséré pendant le processus de construction des paquets concernant le noyau ; de ce fait, vous pouvez mettre toute directive acceptée par Make dans ce fichier (soyez simplement très vigilant à ce que vous faites). Si le fichier de configuration personnel ~/.kernel-pkg.conf existe, il est chargé en priorité par rapport à celui générique du système /etc/kernel-pkg.conf.

Toutes les variables ont des valeurs acceptables par défaut, et peuvent être modifiées ponctuellement ou pour un utilisateur grâce aux variables d'environnement. Certaines de ces variables peuvent de nouveau être modifiées par les options de make-kpkg.

Actuellement, les variables modifiables par l'utilisateur sont :

maintainer

Le responsable local des paquets kernel-*. Définie lors de l'installation du paquet par le script postinst. Modifiable grâce à la variable d'environnement KPKG_MAINTAINER. Notez bien que toute apostrophe ' doit être protégée, comme dans : maintainer = John O'\''Brien. Oui, c'est très laid, mais ça marche.

email

L'adresse de ce responsable. Définie lors de l'installation du paquet par postinst. Modifiable grâce à la variable d'environnement KPKG_EMAIL.

pgp

Nom à rechercher dans la base de données pgp si des modules distincts (tels que pcmcia, etc.) sont construits dans /usr/src/modules/. Modifiable par la variable d'environnement PGP_SIGNATURE, puis (encore) modifiable par l'option --pgpsign de make-kpkg. Réglée par défaut à maintainer. (Optionnelle)

debian

Le numéro de révision Debian des paquets du noyau. Modifiable par la variable d'environnement DEBIAN_REVISION, puis (encore) modifiable par l'option --revision de make-kpkg. Réglée par défaut à 10.0.0.Custom (Facultative)

debian_revision_mandatory

Normalement pas définie. Si cette variable, ou la variable d'environnement DEBIAN_REVISION_MANDATORY sont définies, l'omission d'un numéro de révision Debian provoquera une erreur (et make-kpkg ne fournira pas la valeur 10.0.0.Custom par défaut)

link_in_boot

À mettre à « True » si vous voulez que le lien symbolique vmlinuz vers l'image du noyau soit dans /boot plutôt que dans / par défaut. Modifiable par la variable d'environnement LINK_IN_BOOT qui n'est pas définie par défaut. (Optionnelle)

kimage

Le type de l'image du noyau (zImage, ou bzImage, par exemple). Modifiable par la variable d'environnement IMAGE_TYPE, puis (encore) modifiable par les options --zimage ou --bzimage de make-kpkg. Valeur par défaut : bzImage. (Optionnelle)

no_symlinks

Pour créer un lien symbolique vers le fichier image du noyau. Modifiable par la variable d'environnement NO_SYMLINK Exacte opposée de reverse_symlinks. Peut être utilisé en conjonction avec link_in_boot. L'image sera rangée dans vmlinuz (au lieu de /boot/vmlinuz-X.X.XX). L'ancien vmlinuz sera, dans tous les cas, déplacé vers vmlinuz.old (Normalement, ce déplacement n'a lieu que si la nouvelle image diffère de l'ancienne). Vous êtes limité à deux images, à moins de lancer d'autres commandes pour sauvegarder les images plus anciennes. Cette option concerne les gens qui ont un répertoire /boot dans leur système et qui n'utilisent pas de liens symboliques (et qui, de ce fait, utilisent loadlin pour démarrer leur système). Cette option est un Bidouillage. Valeur non définie par défaut (optionnelle).

reverse_symlinks

Pour utiliser les liens symboliques vers le fichier image dans le sens inverse (dans ce cas, c'est le vrai fichier qui n'a pas le numéro de version, et c'est le lien qui porte le numéro). Modifiable par la variable d'environnement REVERSE_SYMLINK Exacte opposée de no_symlinks. Peut être utilisé avec link_in_boot de la même façon que no_symlinks, sauf que c'est /boot/vmlinuz-X.XX qui est le lien symbolique vers la véritable nouvelle image, vmlinuz. Là encore, vous êtes limité à deux images en tout, sauf si vous lancez d'autres commandes. Les anciens liens symboliques restent, pointant dans le vide. Cette option sert à ceux qui ont un /boot sous umsdos, qui ne voit pas le lien en DOS, mais veulent connaître la version de l'image quand ils sont sous Linux. Cette option est un Bidouillage. Valeur non définie par défaut (optionnel).

patch_the_kernel

Variable réservée aux experts. Si elle est réglée à « YES » (la variable d'environnement PATCH_THE_KERNEL a priorité sur celle-ci), le processus de création du paquet lance run-parts sur /usr/src/kernel-patches/$(architecture)/apply et inverse son effet (du moins l'espère-t-on) pendant le « clean » en lançant run-parts sur /usr/src/kernel-patches/$(architecture)/unpatch. L'architecture spéciale « all » est utilisée pour les patches indépendants de l'architecture.

config_target

Définit la phase de configuration à exécuter. La cible par défaut est oldconfig, ce qui correspond bien à des exécutions non (ou très peu) interactives. Si vous mettez patch_the_kernel à « YES » et que certains patches modifient la liste des réglages de configuration offerts, vous voudrez probablement choisir une autre cible (menuconfig ou xconfig, par exemple). (La variable d'environnement CONFIG_TARGET a priorité sur cette option.) Si la valeur de config_target est différente de config, oldconfig, menuconfig ou xconfig, l'option se réinitialisera à oldconfig.

use_saved_config

Variable réservée aux experts. Si elle est réglée à « NO » (la variable d'environnement USE_SAVED_CONFIG a priorité sur celle-ci), le fichier .config.save situé dans le répertoire le plus haut est ignoré.

root_cmd

Est une variable dont le but est d'être transmise à dpkg-buildpackage dans la cible buildpackage. Elle doit fournir un moyen d'obtenir les droit d'accès du super-utilisateur ( `sudo' ou `fakeroot' par exemple), un peu à la façon de l'option -r de dpkg-buildpackages. La variable d'environnement ROOT_CMD a priorité sur celle-ci. La variable d'environnement UNSIGN_SOURCE fournit à cette commande l'option qui force dpkg-buildpackage à ne pas signer la source, et de la même façon, la variable d'environnement UNSIGN_CHANGELOG fournit à cette commande l'option qui force dpkg-buildpackage à ne pas signer le changelog. Là encore, cette variable n'est utile que pour la cible buildpackage. Réglez la variable d'environnement ROOT_CMD si vous voulez juste construire l'image du noyau, par exemple.

delete_build_link

Lorsque réglée à YES, supprime le lien symbolique /lib/modules/$VERSION/build pointant sur le paquet .deb. La variable d'environnement DELETE_BUILD_LINK a priorité sur cette option.

do_clean

Réglée à tout sauf YES, renoncera à lancer le make clean sur l'arborescence des sources du noyau après la construction du paquet de l'image du noyau. La variable d'environnement CLEAN_SOURCE a priorité sur cette option.

install_vmlinux

Réglée à YES, installe aussi l'image non compressée du noyau au format ELF en plus de l'image compressé (vmlinuz). Cette image est indispensable à oprofile (oprofile.sourceforge.net, pour i386 uniquement) pour l'optimisation du noyau et de l'espace utilisateur.

source_clean_hook

Lorsqu'il pointe sur un programme, celui-ci est alors exécuté sur la racine (temporaire) de l'arborescence du noyau avant l'empaquetage des sources, ./debian/tmp-source/usr/src/kernel-source-X.X.XX. Aucun effet sur quoi que ce soit d'autre que les sources en cours d'empaquetage. Ce script agit sur le répertoire courant et ses fils, et l'arborescence originale des sources demeure inchangée. Utile pour faciliter la cure d'amaigrissement des sources du noyau en cours d'empaquetage (en supprimant par exemple les répertoires de contrôle de version, ou en supprimant les architectures non voulues).

header_clean_hook

Lorsqu'il pointe sur un programme, celui-ci est alors lancé sur la racine des répertoires des en-têtes du noyau avant leur empaquetage. Aucun effet sur quoi que ce soit d'autre que les sources en cours d'empaquetage. Ce script agit sur le répertoire courant et ses fils, et l'arborescence originale des sources demeure inchangée. Utile pour faciliter la cure d'amaigrissement des en-têtes du noyau en cours d'empaquetage (en supprimant par exemple les répertoires de contrôle de version, ou en se débarrassant des architectures non désirées).

doc_clean_hook

Lorsqu'il pointe sur un programme, celui-ci est alors exécuté sur la racine de l'arborescence de la documentation avant son empaquetage. Aucun effet sur quoi que soit d'autre que la documentation en cours d'empaquetage. Ce script agit sur le répertoire courant et ses fils, et l'arborescence originale demeure inchangée. Utile pour faciliter la cure d'amaigrissement de la documentation du noyau en cours d'empaquetage (en supprimant par exemple les répertoires de contrôle de version, ou en se débarrassant des architectures non désirées).

extra_docs

Cette variable pourra contenir le chemin vers toute documentation supplémentaire qui sera alors installée dans le répertoire /usr/share/doc/kernel-image-X.X.XX/. Il n'y a pas de détection de conflit de noms, et les fichiers ne sont pas compressés. De ce fait, si vous voulez que ces fichiers soient compressés, compressez-les et indiquez alors le chemin vers le fichier compressé. La variable d'environnement EXTRA_DOCS a priorité sur cette option, et indiquera certainement la manière de spécifier la documentation supplémentaire.

kpkg_follow_symlinks_in_src

Cette option est particulièrement utile à ceux qui se servent d'un ensemble de liens symboliques pour compiler leurs noyaux. Avec cette option, les paquets kernel-source et kernel-header ne seront pas une simple collection de liens morts, car les liens symboliques auront été suivis. Notez bien que tout lien symbolique présent dans les sources du noyau sera résolu. La variable d'environnement KPKG_FOLLOW_SYMLINKS_IN_SRC a priorité sur cette option.

make_libc_headers

Variable pour le responsable de la libc6 lorsqu'il compile la libc6, afin d'empaqueter aussi les en-têtes correspondants. N'Y TOUCHEZ PAS à moins de savoir ce que vous faites, car une différence entre les en-têtes que vous empaquetez et la libc6 peut tout à fait amener de subtiles instabilités dans tous les codes compilés sur votre machine. Vous êtes prévenu. La variable d'environnement MAKE_LIBC_HEADERS a priorité sur cette option.

CONCURRENCY_LEVEL

Si elle est définie, cette variable 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. Doit être, si elle est définie, un (petit) entier.

ARCH_IN_NAME

Si elle est définie, cette variable force make-kpkg à utiliser un nom rallongé pour le 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. Notez bien que seul le nom du paquet est changé, pas l'emplacement des modules, etc.

CONFDIR

Cette variable pourra pointer sur un répertoire contenant les fichiers .config spécifiques aux différentes architectures (consultez /usr/share/kernel-package/Config pour voir des exemples). Pratique pour compiler pour plusieurs architectures. Pointe par défaut sur /usr/share/kernel-package/Config

IMAGEDIR

Si vous voulez que l'image soit stockée ailleurs que dans /boot , définissez le répertoire de destination dans cette variable. Cela pourra être utile aux utilisateurs de loadlin. Pointe par défaut sur /boot.

MODULE_LOC

Réglez cette variable, soit dans votre environnement, soit dans le fichier de configuration, afin qu'elle pointe sur l'endroit où sont situés les modules additionnels. Pointe par défaut sur /usr/src/modules

CONFDIR

Réglez cette variable, soit dans votre environnement, soit dans le fichier de configuration, afin qu'elle pointe sur l'endroit où sont situés les fichiers de configuration du noyau. Pointe par défaut sur /usr/share/kernel-package/Config

PATCH_DIR

Réglez cette variable, soit dans votre environnement, soit dans le fichier de configuration, afin qu'elle pointe sur l'endroit où sont situés les patches additionnels du noyau. Pointe par défaut sur /usr/src/kernel-patches/ARCHITECTURE

ALL_PATCH_DIR

Réglez cette variable, soit dans votre environnement, soit dans le fichier de configuration, afin qu'elle pointe sur l'endroit où sont situés les patches additionnels du noyau non liés à des architectures. Pointe par défaut sur /usr/src/kernel-patches/all

Le contenu d'une variable est définie de la façon suivante :

a)

Les valeurs par défaut sont présentes dans le fichier « rules ». Ces valeurs sont utilisées si aucun réglage n'est fait.

b)

Les variables peuvent être réglées dans le fichier de configuration /etc/kernel-pkg.conf. Ces valeurs ont priorité sur les valeurs par défaut.

c)

Les variables peuvent aussi être réglées en donnant une valeur à la variable d'environnement correspondante. Ces valeurs ont priorité sur le fichier de configuration et sur les valeurs par défaut.

d)

Par l'utilisation des options de make-kpkg , ou, lorsqu'on utilise directement les fichiers « rules », sur la ligne de commande.

# xxx/rules DEBIAN_REVISION=2.0a kernel_image

Cette commande a priorité sur toutes les méthodes décrites ci-dessus.

Le fichier décrit ici est /etc/kernel-pkg.conf. ou ~/.kernel-pkg.conf.

make-kpkg(1), kernel-img.conf(5), make(1), le manuel GNU Make.

Il n'y a aucun bogue. Toute ressemblance avec un bogue serait du délire. Vraiment.

Cette page a été écrite par Manoj Srivastava <srivasta@debian.org>, pour le système Debian GNU/Linux.

Sylvain Cherrier <sylvain.cherrier@free.fr> Juillet 2004.