Content-type: text/html Man page of KERNEL-PKG.CONF

KERNEL-PKG.CONF

Section: Manuel Debian GNU/Linux (5)
Updated: 7 janvier 1997
Index Return to Main Contents

NOM

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

SYNOPSIS

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

DESCRIPTION

Les fichiers /etc/kernel-pkg.conf ou ~/.kernel-pkg.conf sont en fait des morceaux de code de type Makefile inclus dans le processus de construction du paquet du noyau. Vous pourrez inclure de la sorte n'importe quelle directive de Makefile dans ce fichier (vérifiez simplement que vous savez vraiment ce que vous faites). S'il existe un fichier de configuration ~/.kernel-pkg.conf, il sera prioritaire sur le fichier de configuration du système /etc/kernel-pkg.conf.

Toutes les variables ont des valeurs raisonnables par défaut, et peuvent être outrepassées ponctuellement ou sur la base de choix de l'utilisateur grâce aux variables d'environnement. Certaines de ces variables peuvent de plus être modifiées grâce à des options de make-kpkg.

Les variables actuellement modifiables par l'utilisateur sont les suivantes :

maintainer: Mainteneur local des paquets kernel-*. Défini lors de l'installation du paquet par le script de post-installation. Il est possible de l'outrepasser grâce à la variable d'environnement KPKG_MAINTAINER. Veuillez noter que tout signe de type « ' » doit être protégé, comme dans maintainer = John O'\''Brien. Oui, ce n'est pas terrible, mais ça marche.
email: L'adresse de courriel de cette personne. Définie lors de l'installation du paquet par le script de post-installation. Il est possible de l'outrepasser grâce à la variable d'environnement KPKG_EMAIL.
pgp: Nom à rechercher dans la base de données pgp si des modules séparés (tels que pcmcia, etc.) ont été compilés dans /usr/src/modules/. Il est possible de l'outrepasser grâce à la variable d'environnement PGP_SIGNATURE, et il peut être (à nouveau) outrepassé par l'option --pgpsign de make-kpkg. Valeur par défaut : maintainer. (Optionnel)
debian: Version des paquets du noyau, incluant aussi les versions officielles (upstream). Réglée à « YES », elle entraîne l'exécution d'un clean pour la version et la révision Debian. Modifiable par la variable d?environnement DEBIAN_REVISION, puis (encore) modifiable par l?option --revision de make-kpkg. Réglée par défaut à <VERSION>-10.0.0.Custom. (Optionnel)
debian_revision_mandatory: Habituellement non définie. Si elle, ou la variable d'environnement DEBIAN_REVISION_MANDATORY, sont définies, alors l'absence de numéro de révision Debian entraînera une erreur (et make-kpkg ne fournira pas la valeur par défaut « 10.0.0.Custom »).
link_in_boot: Mettre à « True » si vous voulez que le lien symbolique pointant vers l'image du noyau, à savoir vmlinuz, soit dans /boot plutôt que dans /. Il est possible de l'outrepasser avec la variable d'environnement LINK_IN_BOOT. Non renseigné par défaut. (Optionnel)
kimage: Type d'image du noyau (zImage ou bzImage par exemple). Il est possible de l'outrepasser grâce à la variable d'environnement IMAGE_TYPE, et il est possible de l'outrepasser (de nouveau) grâce aux options --zimage ou --bzimage de make-kpkg. Valeur par défaut : bzImage. (Optionnel)
no_symlinks: Définit s'il faut utiliser des liens symboliques avec le fichier image. Il est possible de l'outrepasser grâce à la variable d'environnement NO_SYMLINK et est l'opposée de reverse_symlinks. Elle peut être utilisée avec link_in_boot.L'image réelle est mise dans vmlinuz, au lieu de /boot/vmlinuz-X.X.XX. L'ancien vmlinuz est renommé d'office en vmlinuz.old. (Normalement, cela n'est fait que si la version de la nouvelle image est différente de l'ancienne). Vous ne pouvez avoir que deux images, à moins de prendre des mesures pour conserver des copies des anciennes images. Cela peut servir à ceux qui ont /boot sur un système qui n'utilise pas les liens symboliques ; ils utilisent aussi loadlin comme programme de démarrage. C'est un bidouillage. La valeur par défaut est « No ».
reverse_symlinks: Définit s'il faut utiliser des liens symboliques inversés avec le fichier image (c'est-à-dire que le fichier réel est celui qui n'a pas de numéro de version et c'est le lien qui possède le numéro de version). Il est possible de l'outrepasser grâce à la variable d'environnement REVERSE_SYMLINK et est l'opposée de no_symlinks. Elle peut être utilisée avec link_in_boot. Tout se passe comme avec no_symlinks, sauf que /boot/vmlinuz-X.X.XX est un lien symbolique vers la nouvelle image réelle, vmlinuz. Là aussi, vous ne pouvez avoir que deux images, à moins de prendre d'autres mesures. Les liens symboliques plus anciens sont laissés ballants. Cela peut servir aux gens qui ont /boot sur umsdos et qui ne peuvent voir les liens symboliques dans dos mais veulent connaître la version de l'image quand ils sont dans Linux. C'est un bidouillage. La valeur par défaut est « No ».
patch_the_kernel: Variable réservée seulement aux experts. Si elle est réglée à « YES » (la variable d'environnement PATCH_THE_KERNEL l'outrepasse), le processus de construction déclenche l'exécution de run-parts sur /usr/src/kernel-patches/$(architecture)/apply et (si tout se passe bien) lance l'opération inverse lors du nettoyage (NdT : clean) en exécutant run-parts sur /usr/src/kernel-patches/$(architecture)/unpatch. L'architecture spéciale « all » sert aux patches indépendants de toute architecture.
config_target: Choix du type de configuration à exécuter. Par défaut, c'est « oldconfig », ce qui est pratique pour les lancements non interactifs (ou aux interactions réduites au minimum). Si vous avez défini patch_the_kernel à « YES » et que certains patches modifient les choix de configuration disponibles, vous voudrez probablement un autre type (telle que menuconfig ou xconfig). (La variable d'environnement CONFIG_TARGET outrepasse ce choix). Si la valeur de config_target n'est ni config, oldconfig, menuconfig ou xconfig, elle est alors réinitialisée à oldconfig.
use_saved_config: Variable réservée seulement aux experts. Si elle est réglée à « NO » (la variable d'environnement USE_SAVED_CONFIG outrepasse cela), le fichier .config.save du répertoire au sommet de l'arborescence est ignoré.
root_cmd: C'est une variable dont le but est d'être transmise à dpkg-buildpackage dans la cible buildpackage. Elle doit fournir un moyen d'obtenir les droits d'accès du superutilisateur ( « sudo » ou « fakeroot » par exemple), un peu à la façon de l'option -r de dpkg-buildpackage. 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: Si elle est définie à « YES », un make clean sera lancé 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: Si elle est réglée à « YES », l'image non compressée du noyau au format ELF sera installée 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.
image_clean_hook: Lorsqu'elle correspond à un programme, celui-ci est alors exécuté sur la racine (temporaire) de l'arborescence du noyau avant l'empaquetage des sources. Cela n'a aucun effet sur quoi que ce soit d'autre que les sources en cours d'empaquetage. Si le script agit sur le répertoire courant et ses fils, l'arborescence originale des sources demeure inchangée. Utile pour faciliter le modelage des sources du noyau en cours d'empaquetage.
source_clean_hook: Lorsqu'il correspond à un programme, celui-ci est alors lancé sur la racine des répertoires des en-têtes du noyau avant leur empaquetage, ./debian/tmp-source/usr/src/kernel-source-X.X.XX. Cela n'a aucun effet sur quoi que ce soit d'autre que les sources en cours d'empaquetage. Si le script agit sur le répertoire courant et ses fils, l'arborescence originale des sources demeure inchangée. Utile pour faciliter le modelage 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).
header_clean_hook: Lorsqu'il correspond à un programme, celui-ci est alors lancé sur la racine des répertoires des en-têtes du noyau avant leur empaquetage. Cela n'a aucun effet sur quoi que ce soit d'autre que les sources en cours d'empaquetage. Si le script agit sur le répertoire courant et ses fils, 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 correspond à un programme, celui-ci est alors exécuté sur la racine de l'arborescence de la documentation avant son empaquetage. Cela n'a aucun effet sur quoi que soit d'autre que la documentation en cours d'empaquetage. Si le script agit sur le répertoire courant et ses fils, l'arborescence originale demeure inchangée. Utile pour faciliter le modelage 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 qui, lorsqu'il compile la libc6, empaquette 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 vraiment déclencher 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.
INITRD_CMD: Réglez cette variable en lui donnant une liste d'exécutables (séparé par des espaces) permettant la création du disque virtuel (RAM Disk) initial. Elle n'a d'effet que si vous installez une image du noyau qui utilise un disque virtuel au démarrage. Les commandes indiquées doivent être directement compatibles avec mkinitrd. Cette variable définit le mode de construction par défaut du script post-installation lors de l'installation, qui peut être outrepassée par l'administrateur pour chacune des cibles grâce à /etc/kernel-img.conf. Si cette liste n'est pas définie, elle pointe par défaut sur un sous-ensemble de mkinitrd mkinitrd.yaird mkinitramfs, ce sous-ensemble étant choisi selon la version du noyau en cours de construction, afin que chacun puisse faire ses réglages manuellement (s'il sait ce qu'il fait).
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 définies 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.

FICHIERS

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

VOIR AUSSI

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

BOGUES

Il n'y a pas d'erreur. Toute ressemblance avec un bogue est du délire. Vraiment.

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.

This document was created by man2html, using the manual pages.
Time: 12:37:45 GMT, March 12, 2007