Manuel Debian Live

À propos

1. À propos de ce manuel

1.1 Pour les impatients
1.2 Terminologie
1.3 Auteurs
1.4 Contribuer à ce document
1.4.1 Appliquer des modifications
1.4.2 Traduction

2. À propos du projet Debian Live

2.1 Motivation
2.1.1 Quel est le problème avec les systèmes live actuels
2.1.2 Pourquoi créer notre propre système live?
2.2 Philosophie
2.2.1 Seulement des paquets inchangés de Debian «main»
2.2.2 Pas de configuration des paquets du système live
2.3 Contact

Utilisateur

3. Installation

3.1 Exigences
3.2 Installation de live-build
3.2.1 À partir du dépôt Debian
3.2.2 À partir du code source
3.2.3 À partir des instantanés
3.3 Installation de live-boot et live-config
3.3.1 À partir du dépôt Debian
3.3.2 À partir du code source
3.3.3 À partir des instantanés

4. Les bases

4.1 Qu'est-ce c'est un système live?
4.2 Premières étapes: la construction d'une image ISO hybride
4.3 Utilisation d'une image ISO hybride live
4.3.1 Graver une image ISO sur un support physique
4.3.2 Copie d'une image ISO hybride sur une clé USB
4.3.3 Démarrer le support live
4.4 Utiliser une machine virtuelle pour les tests
4.4.1 Test d'une image ISO avec QEMU
4.4.2 Test d'une image ISO avec virtualbox-ose
4.5 Construction d'une image HDD
4.6 Utiliser une image HDD
4.6.1 Test d'une image HDD avec Qemu
4.6.2 Utilisation de l'espace disponible sur une clé USB
4.7 Construction d'une image netboot
4.7.1 Serveur DHCP
4.7.2 Serveur TFTP
4.7.3 Serveur NFS
4.7.4 Guide pratique pour expérimenter avec une image Netboot
4.7.5 Qemu
4.7.6 VMWare Player

5. Aperçu des outils

5.1 Le paquet live-build
5.1.1 La commande lb config
5.1.2 La commande lb build
5.1.3 La commande lb clean
5.2 Le paquet live-boot
5.3 Le paquet live-config

6. Gestion d'une configuration

6.1 Traiter les modifications de configuration
6.1.1 Pourquoi utiliser des scripts auto? Que font-ils?
6.2 Utilisez scripts auto d'exemple
6.3 Cloner une configuration publiée via Git

7. Vue d'ensemble de la personnalisation

7.1 Configuration pendant la construction vs. l'amorçage
7.2 Étapes de la construction
7.3 Supplément lb config avec des fichiers
7.4 Tâches de personnalisation

8. Personnalisation de l'installation de paquets

8.1 Sources des paquets
8.1.1 Distribution, archive areas et mode
8.1.2 Miroirs de distribution
8.1.3 Miroirs de distribution utilisés au temps de construction
8.1.4 Miroirs de distribution utilisés au moment de l'exécution
8.1.5 Dépôts additionnels
8.2 Choisir les paquets à installer
8.2.1 Listes de paquets
8.2.2 Using metapackages
8.2.3 Listes de paquets locaux
8.2.4 Listes locaux de paquets binaires
8.2.5 Générer listes de paquets
8.2.6 Utilisant des conditionnels dans les listes de paquets
8.2.7 Tâches de bureau et de la langue
8.3 Installation des paquets modifiés ou de tiers
8.3.1 Utilisant packages.chroot pour installer paquets personnalisés
8.3.2 Utiliser un dépôt APT pour installer des paquets personnalisés.
8.3.3 Les paquets personnalisés et APT
8.4 Configuration d'APT au moment de la construction
8.4.1 Choisir apt ou aptitude
8.4.2 Utilisation d'un proxy avec APT
8.4.3 Tweaking APT to save space
8.4.4 Passer des options à apt ou aptitude
8.4.5 APT pinning

9. Personnalisation des contenus

9.1 Includes
9.1.1 Live/chroot local includes
9.1.2 Binary local includes
9.2 Hooks
9.2.1 Live/chroot local hooks
9.2.2 Hooks au moment du démarrage
9.2.3 Binary local hooks
9.3 Préconfigurer questions de debconf

10. Personnalisation des comportements au moment de l'exécution

10.1 Personnalisation de l'utilisateur Live
10.2 Personnalisation des paramètres régionaux et de la langue
10.3 Persistance
10.3.1 Le fichier live-persistence.conf
10.3.2 Utilisation de plusieurs dispositifs de persistance

11. Personnalisation de l'image binaire

11.1 Chargeur d'amorçage
11.2 Métadonnées ISO

12. Personnalisation de l'installateur Debian

12.1 Types de l'installateur Debian
12.2 Personnalisation de l'installateur Debian par préconfiguration
12.3 Personnalisation de contenu pour l'Installateur Debian

Projet

13. Rapporter des bogues

13.1 Problèmes connus
13.2 Reconstruire à partir de zéro
13.3 Utilisez paquets mis à jour
13.4 Recueillir l'information
13.5 Isoler le cas qui échoue, si possible
13.6 Utilisez le paquet adéquat pour rapporter le bogue
13.6.1 Au moment de la construction tandis l'amorçage
13.6.2 Au moment de la construction tandis l'installation de paquets
13.6.3 Au moment du démarrage
13.6.4 Au moment de l'exécution
13.7 Faire les recherches
13.8 Où rapporter les bogues

14. Style du code

14.1 Compatibilité
14.2 Indentation
14.3 Adaptateur
14.4 Variables
14.5 Autres

15. Procédures

15.1 Télécharger Udebs
15.2 Évolutions majeures
15.3 Èvolutions mineures
15.3.1 Dernière évolution mineure d'une version Debian
15.3.2 Modèle pour l'annonce d'une évolution mineure

Exemples

16. Exemples

16.1 En utilisant les exemples
16.2 Tutorial 1: Une image standard
16.3 Tutoriel 2: Un utilitaire de navigateur Web
16.4 Tutoriel 3: Une image personnalisée
16.4.1 Première révision
16.4.2 Deuxième révision
16.5 Un client Kiosk VNC
16.6 Une image de base pour une clé USB de 128M
16.7 Un bureau KDE localisé et installateur

Appendix

17. Style guide

17.1 Guidelines for authors
17.1.1 Linguistic features
17.1.2 Procedures
17.2 Guidelines for translators
17.2.1 Translation hints

Manuel Debian Live

Utilisateur

8. Personnalisation de l'installation de paquets

La personnalisation la plus fondamentale d'un système Debian Live peut-être la sélection de paquets à inclure dans l'image. Ce chapitre vous guide tout au long des différentes options dans certains moments de la construction pour personnaliser l'installation des paquets avec live-build. Le plus large choix influençant les paquets qui sont disponibles pour l'installation dans l'image sont les zones de distribution et les sections (archive areas). Afin de garantir 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 backports, paquets expérimentaux ou personnalisés, ou inclure des paquets directement en tant que fichiers. Vous pouvez définir des listes de paquets, incluant les métapaquets qui installent nombreux paquets liés à la fois, telles que les paquets pour un ordinateur de bureau ou langue particulière. Enfin, un certain nombre d'options donnent un certain contrôle sur apt, ou si vous préférez, aptitude, au moment de la construction quand les paquets sont installés. Vous pouvez trouver ces très pratique si vous utilisez un proxy, vous voulez désactiver l'installation des paquets recommandés pour économiser l'espace, ou avez besoin de contrôler quels versions des paquets sont installés via APT pinning, pour n'en nommer quelques possibilités.

8.1 Sources des paquets

8.1.1 Distribution, archive areas et mode

La distribution que vous choisissez a le plus large impact sur les paquets qui sont disponibles à inclure dans votre image live. Indiquez le nom de code, qui est par défaut wheezy pour la version de live-build dans wheezy. Toute distribution actuelle dans l'archive Debian peut être spécifié par son nom de code ici. (Voir Termes pour plus de détails.) L'option --distribution non seulement influence la source des paquets dans l'archive, mais aussi dit live-build comme it doit construire chaque distribution soutenue. Par exemple, pour construire contre unstable, sid, précisez:

$ lb config --distribution sid

Dans l'archive de distribution, les «archive areas» sont les principales divisions de l'archive. Dans Debian, ce sont main, contrib et non-free. Seulement main contient des logiciels qui font partie de la distribution Debian, donc qui est la valeur par défaut. Une ou plusieurs valeurs peuvent être spécifiées, par exemple

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

Soutien expérimental est disponible pour certains dérivés de Debian grâce à l'option --mode. L'option debian est définie par défaut, même si vous êtes en créant sur un système non-Debian. Si vous spécifiez --mode ubuntu ou --mode emdebian, les noms de distribution et des areas des archives pour les dérivés spécifiés sont soutenues au lieu 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 principalement responsables d'aider les utilisateurs de ces options. Le projet Debian Live, à son tour, fournit un soutien de développement sur une base des meilleurs efforts seulement, en fonction des commentaires sur les projets dérivés que nous n'avons pas développé ou soutenu nous-mêmes.

8.1.2 Miroirs de distribution

L'archive Debian est répliqué sur un grand réseau de miroirs autour du monde pour que les habitants dans chaque région puissent choisir un miroir proche avec la meilleur vitesse de téléchargement. Chacune des options --mirror-* régissent quel miroir de distribution est utilisée à différentes étapes de la construction. Rappelez-vous de Étapes de la construction que l'étape bootstrap c'est quand le chroot est initialement peuplée par debootstrap avec un système minimal, et l'étape chroot c'est 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ées 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.

8.1.3 Miroirs de distribution utilisés au temps de construction

Pour définir les miroirs de distribution utilisés au temps de construction pour pointer vers un miroir local, il suffit de fixer --mirror-bootstrap , --mirror-chroot-security et --mirror-chroot-backports comme suit.

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

Le miroir chroot, spécifié par --mirror-chroot, par défaut, c'est la valeur --mirror-bootstrap.

8.1.4 Miroirs de distribution utilisés au moment de l'exécution

Les options --mirror-binary* régissent les miroirs de distribution placés dans l'image binaire. Ils peuvent être utilisés pour installer des paquets supplémentaires lors de l'exécution du système live. Les valeurs par défaut emploient cdn.debian.net, un service qui choisit un miroir géographiquement proche basé sur le numéro IP de l'utilisateur. C'est un choix approprié lorsque vous ne pouvez pas prédire quel miroir sera mieux pour tous vos utilisateurs. Ou vous pouvez spécifier vos propres valeurs, comme indiqué dans l'exemple ci-dessous. Une image construite avec cette configuration seulement serait appropriée pour les utilisateurs sur un réseau où "mirror" est accessible.

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

8.1.5 Dépôts additionnels

Vous pouvez ajouter d'autres dépôts, élargissant votre choix de paquets au-delà ceux disponibles dans votre distribution cible. Il peut être, par exemple, pour backports, expérimentaux ou des paquets personnalisés. Pour configurer des dépôts supplémentaires, créer les fichiers config/archives/your-repository.list.chroot, et/ou config/archives/your-repository.list.binary. Comme avec les options --mirror-*, elles gouvernent 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 pour les utiliser au moment de 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 au moment de la construction du système live.

deb http://live.debian.net/ sid-snapshots main contrib non-free

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 fichiers config/archives/your-repository.key.{binary,chroot}

Remarque: certains dépôts de paquets préconfigurés sont disponibles pour une sélection facile grâce à l'option --archives, par exemple pour activer les instantanés live, il suffit une simple commande:

$ lb config --archives live.debian.net

8.2 Choisir les paquets à installer

Il y a un certain nombre de façons pour choisir quels paquets live-build installera dans votre image, couvrant une variété de besoins différentes. Vous pouvez tout simplement nommer les paquets individuels à installer dans une liste de paquets. Vous pouvez également choisir métapaquets dans ces listes, ou sélectionner-les en utilisant des champs de paquets de contrôle de fichiers. Et enfin, vous pouvez placer 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.

8.2.1 Listes de paquets

Les listes de paquets sont un excellent moyen d'exprimer quels paquets doivent être installés. La syntaxe de la liste soutient les fichiers inclus et sections conditionnelles qui les rend faciles de construire à partir d'autres listes et de les adapter pour une utilisation dans configurations multiples. Les noms des paquets peuvent également être injectés dans la liste en utilisant assistants de shell au moment de la construction.

Remarque: Le comportement de live-build pour spécifier un paquet qui n'existe pas est déterminé par votre choix de l'utilité APT. Voir Choisir apt ou aptitude pour plus de détails.

8.2.2 Using metapackages

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

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

Ceci remplace l'ancienne méthode des listes prédéfinies soutenue dans live-build 2.x. Contrairement aux listes prédéfinies, les métapaquets ne sont pas spécifiques du projet Debian Live. 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 si elle peut contenir une poignée de faux résultats qui correspondent avec le nom, mais ne sont pas métapaquets) est de faire correspondre le nom du paquet avec:

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

En plus, vous trouverez d'autres métapaquets à des fins diverses. Certains sont sous-ensembles de paquets de tâches plus larges, comme gnome-core, tandis que d'autres sont 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, installer le paquet debtags et lister tous les paquets avec le tag role::metapackage comme suit:

$ debtags search role::metapackage

8.2.3 Listes de paquets locaux

Si vous ajoutez métapaquets dans une liste, 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 packages 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 ne spécifiez pas le suffixe de l'étape, la liste sera utilisée pour les deux étapes. Normalement, vous voulez spécifier .list.chroot de sorte que les paquets seront 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.

8.2.4 Listes locaux de paquets binaires

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 les supports 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.

8.2.5 Générer listes de paquets

Il arrive parfois que la meilleure façon de composer une liste est 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

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:

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

8.2.6 Utilisant des conditionnels 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 instructions conditionnelles dans les listes de paquets. Généralement, cela signifie une option lb config majuscule et avec tirets changés en caractères de soulignement. Mais en pratique, c'est seulement ceux 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 spécifié:

#if ARCHITECTURES amd64
ia32-libs
#endif

Vous pouvez tester pour un certain nombre de valeurs, par exemple pour installer memtest86+ si --architectures i386 ou --architectures amd64 est spécifié:

#if ARCHITECTURES i386 amd64
memtest86+
#endif

Vous pouvez également tester contre des variables qui peuvent contenir plus d'une valeur, par exemple pour installer vrms si contrib ou non-free est spécifié via --archive-areas:

#if ARCHIVE_AREAS contrib non-free
vrms
#endif

Un conditionnel peut entourer une directive #include:

#if ARCHITECTURES amd64
#include <gnome-full>
#endif

L'imbrication des conditionnels n'est pas soutenu.

8.2.7 Tâches de bureau et de la langue

Les tâches de bureau et de la 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 aucun n'est offert dans le menu tasksel. De même, il n'y a pas éléments de menu pour les tâches des langues, mais le choix de la langue de l'utilisateur lors de l'installation influence le choix des tâches de la langue correspondante.

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

Because there is no provision made automatically for language tasks, which include such things as language-specific fonts and input-method packages, if you want them, you need to specify them in your configuration. For example, a GNOME desktop image containing support for Japanese might include these task metapackages:

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

8.3 Installation des paquets modifiés ou de tiers

Tandis qu'il est contre la philosophie de Debian Live, il peut parfois être nécessaire de construire un système live avec des versions modifiées des paquets qui sont dans le dépôt Debian. C'est peut-être pour modifier ou soutenir des fonctionnalités supplémentaires, des langues et branding, ou même pour supprimer des éléments dans les paquets existants qui sont indésirables. De même, les paquets "de 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, être d'intérêt. La création de paquets sur mesure est traité dans le Debian New Maintainers' Guide at ‹http://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é
  • Utilisant packages.chroot est plus simple à réaliser et utile pour les personnalisations ponctuels mais a un certain nombre d'inconvénients, tout en utilisant un dépôt personnalisé APT est plus fastidieux à mettre en place.

    8.3.1 Utilisant packages.chroot pour installer 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 spécifier 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 secure APT.
  • 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 Debian Live dans le contrôle de révision.
  • 8.3.2 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 spécifiez les paquets ailleurs. Voir Choisir les paquets à installer pour plus de détails.

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

    8.3.3 Les paquets personnalisés et APT

    live-build utilise apt pour installer tous les paquets dans le système live donc il héritera les 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 différents numéros de version, APT choisira d'installer le paquet avec la numéro de version supérieur.

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

    8.4 Configuration d'APT au moment de la construction

    Vous pouvez configurer APT par un certain nombre d'options appliquées uniquement au moment de la construction. (La configuration d'APT utilisé dans le système live en fonctionnement peut être configurée de façon normale pour un système live, qui est, 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.

    8.4.1 Choisir apt ou aptitude

    Vous pouvez choisir d'utiliser soit apt ou aptitude. Quel logiciel est utilisé est régi par l'argument --apt de lb config. Choisissez la méthode du comportement préférée 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 spécifié, l'installation va échouer. C'est le réglage par défaut.
  • aptitude: Avec cette méthode, si un paquet manquant est spécifié, l'installation va réussir.
  • 8.4.2 Utilisation d'un proxy avec APT

    Une configuration communément requis par APT est pour faire face à la construction d'une image derrière un proxy. Vous pouvez spécifier votre proxy APT avec les options --apt-ftp-proxy ou --apt-http-proxy si nécessaire, par exemple

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

    8.4.3 Tweaking APT to save space

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

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

    $ lb config --apt-indices false

    Cela ne influencera les entrées dans /etc/apt/sources.list, mais simplement de savoir si /var/lib/apt contient les fichiers indices ou non. La contrepartie est que APT a besoin de ces indices afin d'opérer dans le système live, alors avant de procéder à apt-cache search ou apt-get install, par exemple, l'utilisateur doit faire apt-get update pour créer ces indices.

    If you find the installation of recommended packages bloats your image too much, provided you are prepared to deal with the consequences discussed below, you may disable that default option of APT with:

    $ lb config --apt-recommends false

    The most important consequence of turning off recommends is that live-boot and live-config themselves recommend some packages that provide important functionality used by most Live configurations, such as user-setup which live-config recommends and is used to create the live user. In all but the most exceptional circumstances you need to add back at least some of these recommends to your package lists or else your image will not work as expected, if at all. Look at the recommended packages for each of the live-* packages included in your build and if you are not certain you can omit them, add them back into your package lists.

    The more general consequence is that if you don't install recommended packages for any given package, that is, "packages that would be found together with this one in all but unusual installations" (Debian Policy Manual, section 7.2), some packages that users of your Live system actually need may be omitted. Therefore, we suggest you review the difference turning off recommends makes to your packages list (see the binary.packages file generated by lb build) and re-include in your list any missing packages that you still want installed. Alternatively, if you find you only want a small number of recommended packages left out, leave recommends enabled and set a negative APT pin priority on selected packages to prevent them from being installed, as explained in APT pinning.

    8.4.4 Passer des options à apt ou aptitude

    S'il n'y a pas une option lb config pour modifier le comportement d'APT dans la façon dont vous avez besoin, utiliser --apt-options ou --aptitude-options pour passer des options à votre outil APT configuré. Voir les pages de manuel apt et aptitude pour plus de détails

    8.4.5 APT pinning

    Pour le contexte, s'il vous plaît lire d'abord la page de manuel apt_preferences(5). APT pinning peut être configuré soit au temps de construction, ou encore pendant l'exécution. Pour le premier, créez config/chroot_apt/preferences. Pour ce dernier, créez config/includes.chroot/etc/apt/preferences.

    Imaginons que vous voulez construire un système live wheezy mais il faut installer tous les paquets live qui finissent dans l'image binaire de sid au moment de la construction. Vous devez ajouter sid à votre APT sources et le fixer de sorte que seulement les paquets que vous voulez sont installés au temps de construction et tous les autres sont de la distribution du système cible, wheezy. Ce qui suit devrait accomplir ça:

    $ echo "deb http://mirror/debian sid main" > config/archives/sid.list.chroot
    $ cat >> config/chroot_apt/preferences << END
    Package: live-boot live-boot-initramfs-tools live-config live-config-sysvinit
    Pin: release n=sid
    Pin-Priority: 600

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

    Remarque: Caractères génériques peuvent être utilisés dans les noms des paquets (par exemple Package: live-*) avec la version 0.8.14 ou supérieure d'Apt. Cela signifie qu'il fonctionne avec wheezy en utilisant:

    $ lb config --distribution wheezy

    Une priorité pin négative évitera installér un paquet, comme dans le cas où vous ne voulez pas un paquet qui est recommandé par un autre paquet. Supposons que vous construisez une image LXDE en utilisant task-lxde-desktop dans config/package-lists/lxde-desktop.list.chroot mais ne veulez 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, que à son tour recommande gnome-keyring. Donc, vous voulez omettre le paquet recommandé gnome-keyring. Cela peut être fait en ajoutant la strophe suivante à config/chroot_apt/preferences:

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