diff options
Diffstat (limited to 'markup/pod/live-manual/media/text/fr/user_customization-packages.ssi')
| -rw-r--r-- | markup/pod/live-manual/media/text/fr/user_customization-packages.ssi | 695 |
1 files changed, 695 insertions, 0 deletions
diff --git a/markup/pod/live-manual/media/text/fr/user_customization-packages.ssi b/markup/pod/live-manual/media/text/fr/user_customization-packages.ssi new file mode 100644 index 0000000..ebcfbc0 --- /dev/null +++ b/markup/pod/live-manual/media/text/fr/user_customization-packages.ssi @@ -0,0 +1,695 @@ +: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 |