:B~ Personnalisation de l'installation de paquets

1~customizing-package-installation Personnalisation de l'installation de
paquets

La personnalisation la plus fondamentale d'un système live est sans doute la
sélection des paquets à inclure dans l'image. Ce chapitre vous guide tout au
long des différentes options de construction pour personnaliser
l'installation des paquets avec live-build. Le plus large choix influençant
les paquets disponibles pour l'installation dans l'image sont la
distribution et les zones d'archive. Afin de vous assurer des vitesses de
téléchargement décentes, vous devez choisir un miroir de distribution
proche. Vous pouvez également ajouter vos propres dépôts pour les
rétroportages, paquets expérimentaux ou personnalisés, ou inclure des
paquets directement comme fichiers. Vous pouvez définir des listes de
paquets, incluant des métapaquets qui installent en même temps de nombreux
paquets liés, tels que les paquets pour ordinateurs de bureau ou une langue
particulière. Enfin, un certain nombre d'options donne un certain contrôle
sur /{apt}/, ou si vous préférez, /{aptitude}/, pendant la construction
quand les paquets sont installés. Vous pouvez trouver cela très pratique si
vous utilisez un proxy, si vous voulez désactiver l'installation des paquets
recommandés pour économiser l'espace, ou avez besoin de contrôler quelles
versions des paquets sont installées via APT pinning, pour ne nommer que
quelques possibilités.

2~ Sources des paquets

3~ Distribution, zones d'archive et mode

La distribution que vous choisissez a le plus large impact sur les paquets
qui sont disponibles pour l'inclusion dans votre image live. Indiquez le nom
de code, qui est par défaut ${testing} pour la version de live-build dans
${testing}. Toute distribution actuelle dans l'archive peut être indiquée
par son nom de code ici. (Voir {Termes}#terms pour plus de détails.)
L'option #{--distribution}# influence non seulement la source des paquets
dans l'archive, mais indique également à live-build comment construire
chaque distribution prise en charge. Par exemple, pour construire sur
*{unstable}*, sid, précisez: 

code{

 $ lb config --distribution sid

}code

Dans l'archive de distribution, les zones d'archive («archive areas») sont
les principales divisions de l'archive. Dans Debian, ce sont #{main}#,
#{contrib}# et #{non-free}#. Seule #{main}# contient des logiciels qui font
partie de la distribution Debian, c'est donc la valeur par défaut. Une ou
plusieurs valeurs peuvent être indiquées, par exemple:

code{

 $ lb config --archive-areas "main contrib non-free"

}code

La prise en charge d'experimental est disponible pour certains dérivés de
Debian grâce à l'option #{--mode}#. L'option par défaut est #{debian}# mais
seulement si vous construisez sur un système Debian ou un système
inconnu. Si #{lb config}# est appelé sur un des dérivés pris en charge, il
créera par défaut une image de ce dérivé. Si par exemple #{lb config}# est
lancé en mode #{ubuntu}#, les noms de distribution et des zones d'archives
pour ce dérivé spécifique seront gérés à la place de ceux de Debian. Le mode
modifie également le comportement de live-build en fonction des dérivés.

*{Remarque:}* Les projets pour lesquels ces modes ont été ajoutés sont chargés d'aider les utilisateurs de ces options. Le ${project}, en retour, fournit un soutien de développement sur une base du meilleur effort seulement, en fonction des commentaires sur les projets dérivés que nous n'avons pas développés ou pris en charge nous-mêmes.

3~ Miroirs de distribution

L'archive Debian est répliquée sur un grand réseau de miroirs autour du
monde pour que les habitants de chaque région puissent choisir un miroir
proche ayant la meilleure vitesse de téléchargement. Chacune des options
#{--mirror-*}# régit quel miroir de distribution est utilisé dans les
différentes étapes de la construction. Rappelez-vous dans les {Étapes de la
construction}#stages-of-the-build que l'étape *{bootstrap}* a lieu quand le
chroot est initialement peuplé par /{debootstrap}/ avec un système minimal,
et l'étape *{chroot}* a lieu quand le chroot utilisé pour construire le
système de fichiers du système live est construit. Ainsi, les commutateurs
des miroirs correspondants sont utilisés pour ces étapes et plus tard, dans
l'étape *{binary}*, les valeurs #{--mirror-binary}# et
#{--mirror-binary-security}# sont utilisées, remplaçant tout miroir utilisé
dans une étape antérieure. 

3~distribution-mirrors-build-time Miroirs de distribution utilisés lors de
la construction

Pour définir les miroirs de distribution utilisés pendant la construction
pour pointer vers un miroir local, il suffit de fixer #{--mirror-bootstrap}#
et #{--mirror-chroot-security}# comme suit.

code{

 $ lb config --mirror-bootstrap http://localhost/debian/ \
          --mirror-chroot-security http://localhost/debian-security/

}code

Le miroir chroot, indiqué avec #{--mirror-chroot}#, est par défaut la valeur
de #{--mirror-bootstrap}#.

3~ Miroirs de distribution utilisés pendant l'exécution

Les options #{--mirror-binary*}# régissent les miroirs de distribution
placés dans l'image binaire. Elles peuvent être utilisées pour installer des
paquets supplémentaires lors de l'exécution du système live. Les valeurs par
défaut emploient #{httpredir.debian.org}#, un service qui choisit un miroir
géographiquement proche basé, entre autres choses, sur la famille IP de
l'utilisateur et la disponibilité des miroirs. C'est un choix approprié
lorsque vous ne pouvez pas prédire quel miroir sera le meilleur pour tous
vos utilisateurs. Autrement, vous pouvez indiquer vos propres valeurs, comme
indiqué dans l'exemple ci-dessous. Une image construite avec cette
configuration ne serait appropriée que pour les utilisateurs sur un réseau
où le "#{mirror}#" est accessible.

code{

 $ lb config --mirror-binary http://mirror/debian/ \
          --mirror-binary-security http://mirror/debian-security/ \
          --mirror-binary-backports http://mirror/debian-backports/

}code

3~additional-repositories Dépôts additionnels

Vous pouvez ajouter d'autres dépôts, élargissant votre choix de paquets
au-delà de ceux disponibles dans votre distribution cible. Cela peut être,
par exemple, pour avoir des paquets rétroportés, personnalisés ou
expérimentaux. Pour configurer des dépôts supplémentaires, créez les
fichiers #{config/archives/your-repository.list.chroot}#, et/ou
#{config/archives/your-repository.list.binary}#. Comme avec les options
#{--mirror-*}#, ces fichiers donnent les dépôts utilisés dans l'étape
*{chroot}* lors de la construction de l'image, et dans l'étape *{binary}*,
c'est-à-dire pendant l'exécution du système live.

Par exemple, #{config/archives/live.list.chroot}# vous permet d'installer
les paquets du dépôt des instantanés debian live pendant la construction du
système live.

code{

 deb http://live-systems.org/ sid-snapshots main contrib non-free

}code

Si vous ajoutez la même ligne à #{config/archives/live.list.binary}#, le
dépôt sera ajouté au répertoire #{/etc/apt/sources.list.d/}# de votre
système live.

Si ces fichiers existent, ils seront sélectionnés automatiquement.

Vous devriez également mettre la clé GPG utilisée pour signer le dépôt dans
les fichiers #{config/archives/your-repository.key.{binary,chroot}}#

Si vous avez besoin d'un APT pinning personnalisé, les préférences APT
peuvent être placées dans les fichiers
#{config/archives/your-repository.pref.{binary,chroot}}# et elles seront
automatiquement ajoutées à votre système live dans le répertoire
#{/etc/apt/preferences.d/}#.

2~choosing-packages-to-install Choisir les paquets à installer

Il y a un certain nombre de façons pour choisir quels paquets live-build
s'installeront dans votre image, couvrant toute une variété de besoins. Vous
pouvez tout simplement nommer les paquets individuels à installer dans une
liste de paquets. Vous pouvez également choisir des métapaquets dans ces
listes, ou les sélectionner en utilisant les champs de contrôle de fichiers
des paquets. Enfin, vous pouvez placer des paquets dans votre arbre
#{config/}# qui est bien adapté aux essais de nouveaux paquets ou
expérimentaux avant qu'ils ne soient disponibles sur un dépôt.

3~package-lists Listes de paquets

Les listes de paquets sont un excellent moyen d'exprimer quels paquets
doivent être installés. La syntaxe de la liste gère des sections
conditionnelles, ce qui les rend faciles à construire et à adapter pour leur
utilisation dans des configurations multiples. Les noms des paquets peuvent
également être injectés dans la liste en utilisant des assistants de shell
pendant la construction.

*{Remarque:}* Le comportement de live-build pour indiquer un paquet qui n'existe pas est déterminé par votre choix de l'utilitaire APT. Consultez {Choisir apt ou aptitude}#choosing-apt-or-aptitude pour plus de détails.

3~using-metapackages Utilisation des métapaquets

La façon la plus simple de remplir votre liste de paquets consiste à
utiliser un métapaquet de tâche maintenu par votre distribution. Par
exemple:

code{

 $ lb config
 $ echo task-gnome-desktop > config/package-lists/desktop.list.chroot

}code

Cela remplace l'ancienne méthode des listes prédéfinies gérée dans
#{live-build}# 2.x. Contrairement aux listes prédéfinies, les métapaquets ne
sont pas spécifiques au projet Live Systems. Au lieu de cela, ils sont
maintenus par des groupes de travail spécialisés dans la distribution et
reflètent donc le consensus de chaque groupe sur les paquets pour mieux
servir les besoins des utilisateurs. Ils couvrent également une gamme
beaucoup plus large des cas d'utilisation que les listes prédéfinies qu'ils
remplacent.

Tous les métapaquets de tâches sont préfixés avec #{task-}#, donc un moyen
rapide pour déterminer lesquels sont disponibles (même s'il peut y avoir une
poignée de faux positifs dont le nom correspond mais qui ne sont pas des
métapaquets) est de faire correspondre le nom du paquet avec:

code{

 $ apt-cache search --names-only ^task-

}code

En plus, vous trouverez d'autres métapaquets à des fins diverses. Certains
sont des sous-ensembles de paquets de tâches plus larges, comme
#{gnome-core}#, tandis que d'autres sont des pièces individuelles
spécialisées d'un Debian Pure Blend, comme les métapaquets
#{education-*}#. Pour lister tous les métapaquets dans l'archive, installez
le paquet #{debtags}# et listez tous les paquets ayant l'étiquette
#{role::metapackage}# comme suit:

code{

 $ debtags search role::metapackage

}code

3~ Listes de paquets locaux

Que vous listiez des métapaquets, des paquets individuels ou une combinaison
des deux, toutes les listes de paquets locaux sont stockées dans
#{config/package-lists/}#. Comme plus d'une liste peut être utilisée, cela
se prête bien à une conception modulaire. Par exemple, vous pouvez décider
de consacrer une liste à un choix particulier de bureau, l'autre à une
collection de paquets connexes qui pourraient aussi bien être utilisés
au-dessus d'un bureau différent. Cela vous permet d'expérimenter avec
différentes combinaisons d'ensembles de paquets avec un minimum de tracas en
utilisant des listes communes entre les différents projets d'images live.

Les listes de paquets qui existent dans ce répertoire ont besoin d'avoir un
suffixe #{.list}# pour être traitées, puis un suffixe d'étape supplémentaire
#{.chroot}# ou #{.binary}# pour indiquer à quelle étape la liste est
destinée.

*{Remarque:}* Si vous n'indiquez pas le suffixe de l'étape, la liste sera utilisée pour les deux étapes. Normalement, vous voulez indiquer #{.list.chroot}# de sorte que les paquets soient seulement installés dans le système de fichiers live et ne pas avoir une copie supplémentaire des #{.deb}# placée sur le support.

3~ Listes de paquets locaux pour l'étape binary

Pour faire une liste pour l'étape binary, placez un fichier avec le suffixe
#{.list.binary}# dans #{config/package-lists/}#. Ces paquets ne sont pas
installés dans le système de fichiers live, mais sont inclus sur le support
live sous #{pool/}#. Vous utiliserez généralement cette liste avec une des
variantes d'installation non-live. Comme mentionné ci-dessus, si vous voulez
que cette liste soit la même que votre liste pour l'étape chroot, utilisez
simplement le suffixe #{.list}#. 

3~generated-package-lists Listes de paquets générées

Il arrive parfois que la meilleure façon de composer une liste soit de la
générer avec un script. Toute ligne commençant par un point d'exclamation
indique une commande à exécuter dans le chroot lorsque l'image est
construite. Par exemple, on pourrait inclure la ligne #{! grep-aptavail -n
-sPackage -FPriority standard | sort}# dans une liste de paquets qui permet
de produire une liste triée des paquets disponibles avec #{Priority:
standard}#.

En fait, la sélection des paquets avec la commande #{grep-aptavail}# (du
paquet #{dctrl-tools}#) est si utile que #{live-build}# fournit un script
#{Packages}# à titre de commodité. Ce script accepte deux arguments:
#{field}# et #{pattern}#. Ainsi, vous pouvez créer une liste avec le contenu
suivant:

code{

 $ lb config
 $ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot

}code

3~ Utiliser des conditions dans les listes de paquets

Toutes les variables de configuration de live-build stockées dans
#{config/*}# (sans le préfixe #{LB_}#) peuvent être utilisées dans des
instructions conditionnelles dans les listes de paquets. Généralement, cela
correspond à toute option #{lb config}# en majuscule et avec tirets changés
en caractères de soulignement. Mais en pratique, ce ne sont que celles qui
influencent la sélection des paquets qui font sens, comme #{DISTRIBUTION}#,
#{ARCHITECTURES}# ou #{ARCHIVE_AREAS}#.

Par exemple, pour installer #{ia32-libs}# si #{--architectures amd64}# est
indiqué:

code{

 #if ARCHITECTURES amd64
 ia32-libs
 #endif

}code

Vous pouvez tester pour un certain nombre de valeurs, par exemple pour
installer /{memtest86+}/ si #{--architectures i386}# ou #{--architectures
amd64}# est indiqué:

code{

 #if ARCHITECTURES i386 amd64
 memtest86+
 #endif

}code

Vous pouvez également tester avec des variables pouvant contenir plus d'une
valeur, par exemple pour installer /{vrms}/ si #{contrib}# ou #{non-free}#
est indiqué via #{--archive-areas}#:

code{

 #if ARCHIVE_AREAS contrib non-free
 vrms
 #endif

}code

L'imbrication des conditions n'est pas prise en charge.

% FIXME:

3~ Suppression de paquets lors de l'installation

Il est possible de lister des paquets dans des fichiers utilisant les
extensions #{.list.chroot_live}# et #{.list.chroot_install}# à l'intérieur
du répertoire #{config/package-lists}#. Si une liste «install» et une liste
«live» existent conjointement, les paquets dans la liste
#{.list.chroot_live}# seront supprimés par un hook après l'installation (si
l'utilisateur utilise l'installeur). Les paquets dans la liste
#{.list.chroot_install}# sont présents à la fois dans le système live et
dans le système installé. Il s'agit d'un paramétrage spécial pour
l'installeur et peut se révéler utile si vous avez choisi
#{--debian-installer live}# dans votre configuration, et souhaitez supprimer
des paquets spécifiques aux systèmes live lors de l'installation.

3~desktop-and-language-tasks Tâches de bureau et de langue

Les tâches de bureau et de langue sont des cas particuliers qui ont besoin
d'une certaine planification et de configuration supplémentaire. Dans
l'installateur Debian, si le support a été préparé pour un environnement de
bureau particulier, la tâche correspondante sera automatiquement
installée. Ainsi, il y a tâches internes #{gnome-desktop}#, #{kde-desktop}#,
#{lxde-desktop}# et #{xfce-desktop}#, dont aucune n'est proposée dans le
menu #{tasksel}#. De même, il n'y a pas d'élément de menu pour les tâches de
langue, mais le choix de la langue de l'utilisateur lors de l'installation
influence le choix des tâches de langue correspondantes.

Lors du développement d'une image de bureau live, l'image s'amorce
généralement directement sur un bureau de travail. Les choix de
l'environnement de bureau et la langue par défaut ont été faits pendant la
construction et non pas pendant l'exécution comme dans le cas de
l'installateur de Debian. Cela ne veut pas dire qu'une image live ne
pourrait pas être construite pour prendre en charge plusieurs environnements
de bureau ou plusieurs langues et offrir à l'utilisateur un choix, mais ce
n'est pas le comportement par défaut de live-build.

Comme aucune disposition n'est faite automatiquement pour les tâches de la
langue, qui comprennent des éléments tels que des polices spécifiques à la
langue et des paquets de méthodes de saisie, vous devez les indiquer dans
votre configuration si vous les voulez. Par exemple, une image de bureau
GNOME contenant la prise en charge de l'allemand pourrait inclure les
métapaquets de tâches suivants:

code{

 $ lb config
 $ echo "task-gnome-desktop task-laptop" >> config/package-lists/my.list.chroot
 $ echo "task-german task-german-desktop task-german-gnome-desktop" >> config/package-lists/my.list.chroot

}code

3~kernel-flavour-and-version Version et type de noyau

Un ou plusieurs types de noyau seront inclus dans votre image par défaut, en
fonction de l'architecture. Vous pouvez choisir différents types avec
l'option #{--linux-flavours}#. Chaque type est suffixé à partir de
#{linux-image}# pour former le nom de chaque métapaquet qui dépend à son
tour d'un paquet noyau exact à inclure dans votre image.

Ainsi, par défaut, une image pour l'architecture #{amd64}# comprendra le
métapaquet #{linux-image-amd64}#, et une image pour l'architecture #{i386}#
comprendra le métapaquet #{linux-image-586}#.

Lorsque plus d'une version du paquet du noyau est disponible dans vos
archives configurées, vous pouvez indiquer un nom du paquet du noyau
différent avec l'option #{--linux-packages}#. Par exemple, supposons que
vous construisiez une image pour l'architecture #{amd64}# et ajoutiez
l'archive expérimentale pour faire des essais. Pour installer le noyau
#{linux-image-3.18.0-trunk-amd64}# vous pouvez configurer cette image comme
suit:

code{

 $ lb config --linux-packages linux-image-3.18.0-trunk
 $ echo "deb http://ftp.debian.org/debian/ experimental main" > config/archives/experimental.list.chroot

}code

3~custom-kernels Noyaux personnalisés

Vous pouvez créer et inclure vos propres noyaux personnalisés, à condition
qu'ils soient intégrés dans le système de gestion des paquets Debian. Le
système de live-build ne gère pas les noyaux qui ne sont pas construits sous
forme de paquets #{.deb}#.

La façon correcte et recommandée de déployer vos propres paquets du noyau
est de suivre les instructions dans le #{kernel-handbook}#. N'oubliez pas de
modifier l'ABI et les suffixes de manière appropriée, puis d'inclure une
construction complète des paquets #{linux}# et #{linux-latest}# dans votre
dépôt.

Si vous optez pour la construction des paquets du noyau sans les métapaquets
correspondants, vous devez indiquer une chaîne #{--linux-packages}#
appropriée tel que discuté dans {Version et type de
noyau}#kernel-flavour-and-version. Comme nous l'expliquons dans
{Installation de paquets modifiés ou
tiers}#installing-modified-or-third-party-packages, il est préférable que
vous incluiez vos paquets de noyau personnalisés à votre propre dépôt, bien
que les alternatives discutées dans cette section fonctionnent bien
également.

Donner des conseils sur la façon de personnaliser votre noyau sort du cadre
de ce document. Toutefois, vous devez au moins vous assurer que votre
configuration répond à ces exigences minimales:

_* Utilisez un ramdisk initial.

_* Incluez un module d'union de systèmes de fichiers (par exemple #{aufs}#).

_* Incluez tous les autres modules du système de fichiers requis pour votre
configuration (habituellement #{squashfs}#).

2~installing-modified-or-third-party-packages Installation de paquets
modifiés ou tiers

Bien que ce soit contre la philosophie d'un système live, il peut parfois
être nécessaire de construire un système live avec des versions modifiées
des paquets du dépôt Debian. Cela peut être pour modifier ou prendre en
charge des fonctionnalités supplémentaires, des langues et la marque, ou
même pour supprimer des éléments indésirable dans les paquets existants.De
même, les paquets «tiers» peuvent être utilisés pour ajouter des
fonctionnalités sur mesure et/ou propriétaires.

Cette section ne couvre pas les conseils concernant la construction ou la
maintenance des paquets modifiés. La méthode de Joachim Breitner 'How to
fork privately'
http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html
peut, cependant, vous intéresser. La création de paquets sur mesure est
traitée dans le guide du nouveau mainteneur Debian à
https://www.debian.org/doc/maint-guide/ et ailleurs

Il y a deux façons d'installer des paquets personnalisés modifiés:

_* #{packages.chroot}#

_* Utiliser un dépôt APT personnalisé

Utiliser #{packages.chroot}# est plus simple à réaliser et utile pour les
personnalisations ponctuelles mais a un certain nombre d'inconvénients,
alors qu'utiliser un dépôt personnalisé APT est plus fastidieux à mettre en
place.

3~ Utiliser #{packages.chroot}# pour installer des paquets personnalisés

Pour installer un paquet personnalisé, il suffit de le copier dans le
répertoire #{config/packages.chroot/}#. Les paquets qui sont dans ce
répertoire seront automatiquement installés dans le système live pendant la
construction du système - vous n'avez pas besoin de les indiquer ailleurs.

Les paquets *{doivent}* être nommés de la manière prescrite. Une façon
simple de le faire consiste à utiliser #{dpkg-name}#.

L'utilisation de #{packages.chroot}# pour l'installation de paquets
personnalisés a des inconvénients:

_* Il n'est pas possible d'utiliser APT de façon sécurisée.

_* Vous devez installer tous les paquets appropriés dans le répertoire
#{config/packages.chroot/}#.

_* Il ne se prête pas au stockage de configurations des systèmes live dans
le contrôle de révision.

3~ Utiliser un dépôt APT pour installer des paquets personnalisés.

Contrairement à l'utilisation de #{packages.chroot}#, lorsque vous utilisez
un dépôt personnalisé APT, vous devez vous assurer que vous indiquez les
paquets ailleurs. Voir {Choisir les paquets à
installer}#choosing-packages-to-install pour plus de détails.

S'il peut sembler inutile de créer un dépôt APT pour installer des paquets
personnalisés, l'infrastructure peut être facilement réutilisée à une date
ultérieure pour offrir les mises à jour des paquets modifiés.

3~ Les paquets personnalisés et APT

live-build utilise apt pour installer tous les paquets dans le système live,
il héritera donc des comportements de ce logiciel. Un exemple pertinent est
que (en supposant une configuration par défaut), s'il y a un paquet
disponible dans deux dépôts différents avec des numéros de version
différents, APT choisira d'installer le paquet ayant le numéro de version le
plus grand.

Pour cette raison, vous pouvez incrémenter le numéro de version dans les
fichiers #{debian/changelog}# de vos paquets personnalisés pour vous assurer
que votre version modifiée sera installée au lieu d'une autre provenant des
dépôts officiels Debian. Cela peut aussi être afait en modifiant les
préférences d'APT pinning dans le système live − voir {APT
pinning}#apt-pinning pour plus d'informations.

2~ Configuration d'APT pendant la construction

Vous pouvez configurer APT par un certain nombre d'options appliquées
uniquement pendant la construction. (La configuration d'APT utilisée dans le
système live en fonctionnement peut être configurée de façon normale pour un
système live, c'est-à-dire en incluant les configurations appropriées dans
#{config/includes.chroot/}#.) Pour une liste complète, regardez les options
commençant par #{apt}# dans la page de manuel de #{lb_config}#.

3~choosing-apt-or-aptitude Choisir apt ou aptitude

Vous pouvez choisir d'utiliser soit /{apt}/, soit /{aptitude}/. Le choix du
logiciel utilisé dépend de l'argument #{--apt}# de #{lb config}#. Choisissez
la méthode ayant le comportement que vous préférez pour l'installation de
paquets, la différence notable étant la manière dont les paquets manquants
sont traités.

_* #{apt}#: Avec cette méthode, si un paquet manquant est indiqué,
l'installation va échouer. C'est le réglage par défaut.

_* #{aptitude}#: Avec cette méthode, si un paquet manquant est indiqué,
l'installation va réussir.

3~ Utilisation d'un proxy avec APT

Une configuration communément requise par APT est de gérer la construction
d'une image derrière un proxy. Vous pouvez indiquer votre proxy APT avec les
options #{--apt-ftp-proxy}# ou #{--apt-http-proxy}# si nécessaire, par
exemple

code{

 $ lb config --apt-http-proxy http://proxy/

}code

3~tweaking-apt-to-save-space Régler APT pour économiser de l'espace

Vous pouvez avoir besoin d'économiser de l'espace sur le support d'image,
auquel cas l'une ou l'autre ou les deux options suivantes peuvent être
d'intérêt.

Si vous ne voulez pas inclure les index d'APT dans l'image, vous pouvez les
omettre avec:

code{

 $ lb config --apt-indices false

}code

Cela n'influencera pas les entrées dans #{/etc/apt/sources.list}#, mais
seulement le fait que #{/var/lib/apt}# contienne les fichiers index ou
non. La contrepartie est qu'APT a besoin de ces index afin d'opérer dans le
système live. Par conséquent, avant de procéder à #{apt-cache search}# ou
#{apt-get install}# par exemple, l'utilisateur doit faire #{apt-get update}#
pour créer ces index.

Si vous trouvez que l'installation des paquets recommandés fait trop gonfler
votre image, à condition d'être prêt à faire face aux conséquences décrites
ci-dessous, vous pouvez désactiver l'option par défaut d'APT avec:

code{

 $ lb config --apt-recommends false

}code

La conséquence la plus importante de la désactivation des recommandations
est que #{live-boot}# et #{live-config}# recommandent certains paquets qui
fournissent des fonctionnalités importantes utilisées par la plupart de
configurations live, telles que #{user-setup}# qui est recommandé par
#{live-config}# qui est utilisé pour créer l'utilisateur live. Sauf
exception, vous aurez besoin de rajouter au moins certaines de ces
recommandationss à vos listes de paquets ou votre image ne fonctionnera pas
comme prévu, si elle fonctionne. Regardez les paquets recommandés pour
chacun des paquets #{live-*}# inclus dans votre construction et si vous
n'êtes pas sûr de pouvoir les omettre, ajoutez-les à nouveau dans vos listes
de paquets.

La conséquence la plus générale est que si vous n'installez pas les paquets
recommandés par un paquet, c’est-à-dire les «paquets qu'on trouverait avec
celui-ci dans toute installation standard» (Debian Policy Manual, section
7.2), certains paquets dont vous avez vraiment besoin peuvent être omis. Par
conséquent, nous vous suggérons d'examiner la différence que la
désactivation des recommandations induit sur votre liste de paquets (voir le
fichier #{binary.packages}# généré par #{lb build}#) et incluez dans votre
liste tous les paquets manquants que vous souhaitez toujours
installer. Alternativement, si seulement un petit nombre de paquets que vous
ne souhaitez pas est exclus, laissez les recommandations activées et
définissez une priorité APT pin négative sur les paquets sélectionnés pour
éviter les installer, comme expliqué dans {APT pinning}#apt-pinning.

3~ Passer des options à apt ou aptitude

S'il n'y a pas d'option #{lb config}# pour modifier le comportement d'APT de
la façon dont vous avez besoin, utilisez #{--apt-options}# ou
#{--aptitude-options}# pour passer des options par le biais de l'outil APT
configuré. Consultez les pages de manuel #{apt}# et #{aptitude}# pour les
détails. Notez que les deux options ont des valeurs par défaut que vous
aurez besoin de conserver en plus des remplacements que vous pouvez
fournir. Ainsi, par exemple, supposons que vous ayez inclus quelque chose de
#{snapshot.debian.org}# à des fins de test et que vous vouliez indiquer
#{Acquire::Check-Valid-Until=false}# pour satisfaire APT avec le fichier
#{Release}# obsolète. Vous le feriez comme dans l'exemple suivant, avec
l'ajout de la nouvelle option après la valeur par défaut #{--yes}#:

code{

 $ lb config --apt-options "--yes -oAcquire::Check-Valid-Until=false"

}code

Veuillez lire attentivement les pages de manuel pour bien comprendre ces
options et quand les utiliser. Ce n'est qu'un exemple et ne doit pas être
interprété comme un conseil pour configurer votre image de cette façon. Par
exemple, cette option ne serait pas appropriée pour une version finale d'une
image live.

Pour les configurations plus compliquées concernant des options
#{apt.conf}#, vous pourriez vouloir créer un fichier
#{config/apt/apt.conf}#. Consultez aussi les autres options #{apt-*}# pour
obtenir quelques raccourcis pratiques pour les options fréquemment
utilisées.

3~apt-pinning APT pinning

Pour plus de contexte, veuillez d'abord lire la page de manuel
#{apt_preferences(5)}#. APT pinning peut être configuré soit pendant la
construction, soit pendant l'exécution. Dans le premier cas, créez
#{config/archives/*.pref}#, #{config/archives/*.pref.chroot}#, et
#{config/apt/preferences}#. Dans le second cas, créez
#{config/includes.chroot/etc/apt/preferences}#.

Imaginons que vous voulez construire un système live ${testing} mais qu'il
faut installer tous les paquets live qui finissent dans l'image binaire de
sid pendant la construction. Vous devez ajouter sid à votre fichier APT
sources et fixer tous les paquets live avec une priorité supérieure mais
tous les autres paquets avec une priorité inférieure à la priorité par
défaut de sorte que seuls les paquets que vous voulez soient installés à
partir de sid pendant la construction et que tous les autres viennent de la
distribution du système cible, ${testing}. Ce qui suit devrait accomplir
cela:

code{

 $ echo "deb http://mirror/debian/ sid main" > config/archives/sid.list.chroot
 $ cat >> config/archives/sid.pref.chroot << EOF
 Package: live-*
 Pin: release n=sid
 Pin-Priority: 600

 Package: *
 Pin: release n=sid
 Pin-Priority: 1
 EOF

}code

Une priorité pin négative évitera installer un paquet, comme dans le cas où
vous ne voudriez pas un paquet qui est recommandé par un autre
paquet. Supposons que vous construisiez une image LXDE en utilisant
#{task-lxde-desktop}# dans #{config/package-lists/desktop.list.chroot}# mais
que vous ne vouliez pas que l'utilisateur soit invité à stocker les mots de
passe wifi dans le trousseau de clés. Cette liste comprend /{lxde-core}/,
qui recommande /{gksu}/, qui à son tour recommande /{gnome-keyring}/. Donc,
vous voulez omettre le paquet recommandé /{gnome-keyring}/. Cela peut être
fait en ajoutant ce qui suit à #{config/apt/preferences}#:

code{

 Package: gnome-keyring
 Pin: version *
 Pin-Priority: -1

}code