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, 0 insertions, 695 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 deleted file mode 100644 index ebcfbc0..0000000 --- a/markup/pod/live-manual/media/text/fr/user_customization-packages.ssi +++ /dev/null @@ -1,695 +0,0 @@ -: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 |