Loading

NOM

       kernel-pkg.conf - fichier de configuration pour make-kpkg

SYNOPSIS

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

       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  utilisateur  ~/.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-*  (image,  entêtes,
              documentations, etc). 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    La clé d’indentification à utiliser pour signer le paquet.   En
              général  fournie  à   dpkg-buildpackage  grâce à l’option -k,
              ainsi  qu’aux  modules  de  tierces  parties  par  la   variable
              d’environnement  KMAINT,  si  ces  modules  séparés  (tels que
              pcmcia, etc) sont  construits  dans  le  $MODULE_PATH.   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)   et   les  modificatioins  de  Debian.
environnement DEBIAN_REVISION, puis (encore) modifiable par lâoption
              Modifiable par la variable dâ--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 »).

       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)

       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). (La
              variable d’environnement CONFIG_TARGET outrepasse ce choix).  Si
              la   valeur  de  config_target  est  inconnue,  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.  Par défaut, elle n’est pas définie. Notez qu’elle est
              sensible à la casse, yes ne fonctionnant pas.

       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. Par défaut, elle
              n’est pas définie. Notez qu’elle est sensible à la  casse,  yes
              ne fonctionnant pas.

       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).  Par  défaut,  elle  n’est pas définie.
              Notez qu’elle est sensible à la casse, yes ne fonctionnant  pas.

       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. Par défaut, elle est n’est pas définie.

       make_libc_headers
              Variable pour le responsable de la libc6 qui, lorsqu’il  compile
              la  libc6,  empaquette  aussi  les en-têtes correspondants. NY
              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. Par défaut, elle n’est pas définie.

       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, qu’elle soit dans  d’environnement  ou  dans  le
              fichier  de  configuration,   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  ceux  qui  ont  besoin  de
              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.

              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.