Live manual Debian Live

# Debian Live Manual

# Personnalisation de l'installation de paquets

358

# 8. Personnalisation de l'installation de paquets

359

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

360

8.1 Sources des paquets

361

8.1.1 Distribution, zones d'archive et mode

362

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 buster pour la version de live-build dans buster. Toute distribution actuelle dans l'archive peut être indiquée par son nom de code ici. (Voir Termes 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:

363

$ lb config --distribution sid

364

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:

365

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

366

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.

367

Remarque: Les projets pour lesquels ces modes ont été ajoutés sont chargés d'aider les utilisateurs de ces options. Le Debian Live 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.

368

8.1.2 Miroirs de distribution

369

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

370

8.1.3 Miroirs de distribution utilisés lors de la construction

371

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

372

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

373

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

374

8.1.4 Miroirs de distribution utilisés pendant l'exécution

375

The `--mirror-binary*` options govern the distribution mirrors placed in the binary image. These may be used to install additional packages while running the live system. The defaults employ `deb.debian.org`, a service that chooses a geographically close mirror based, among other things, on the user's IP family and the availability of the mirrors. This is a suitable choice when you cannot predict which mirror will be best for all of your users. Or you may specify your own values as shown in the example below. An image built from this configuration would only be suitable for users on a network where "`mirror`" is reachable.

376

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

377

8.1.5 Dépôts additionnels

378

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.

379

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.

380

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

381

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.

382

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

383

You should also put the ASCII-armored GPG key used to sign the repository into `config/archives/your-repository.key.{binary,chroot}` files.

384

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/`.

385

8.2 Choisir les paquets à installer

386

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.

387

8.2.1 Listes de paquets

388

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.

389

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 pour plus de détails.

390

8.2.2 Utilisation des métapaquets

391

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:

392

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

393

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.

394

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:

395

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

396

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:

397

$ debtags search role::metapackage

398

8.2.3 Listes de paquets locaux

399

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.

400

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.

401

The packages in the `.list.chroot_install` list are present both in the live system and in the installed system.

402

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.

403

8.2.4 Listes de paquets locaux pour l'étape binary

404

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`.

405

8.2.5 Listes de paquets générées

406

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`.

407

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:

408

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

409

8.2.6 Utiliser des conditions dans les listes de paquets

410

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`.

411

Par exemple, pour installer `ia32-libs` si `--architectures amd64` est indiqué:

412

#if ARCHITECTURES amd64
ia32-libs
#endif

413

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

414

#if ARCHITECTURES i386 amd64
memtest86+
#endif

415

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`:

416

#if ARCHIVE_AREAS contrib non-free
vrms
#endif

417

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

418

8.2.7 Suppression de paquets lors de l'installation

419

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.

420

8.2.8 Tâches de bureau et de langue

421

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.

422

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.

423

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:

424

$ 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

425

8.2.9 Version et type de noyau

426

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.

427

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`.

428

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:

429

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

430

8.2.10 Noyaux personnalisés

431

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`.

432

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.

433

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. Comme nous l'expliquons dans Installation de paquets modifiés ou tiers, 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.

434

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:

435

- Utilisez un ramdisk initial.

436

- Incluez un module d'union de systèmes de fichiers (par exemple `aufs`).

437

- Incluez tous les autres modules du système de fichiers requis pour votre configuration (habituellement `squashfs`).

438

8.3 Installation de paquets modifiés ou tiers

439

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ésirables 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.

440

This section does not cover advice regarding building or maintaining modified packages. Joachim Breitner's 'How to fork privately' method from ‹http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html› may be of interest, however. The creation of bespoke packages is covered in the Debian New Maintainers' Guide at ‹https://www.debian.org/doc/manuals/maint-guide/› and elsewhere.

441

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

442

- `packages.chroot`

443

- Utiliser un dépôt APT personnalisé

444

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.

445

8.3.1 Utiliser `packages.chroot` pour installer des paquets personnalisés

446

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.

447

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

448

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

449

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

450

- Vous devez installer tous les paquets appropriés dans le répertoire `config/packages.chroot/`.

451

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

452

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

453

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 pour plus de détails.

454

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.

455

8.3.3 Les paquets personnalisés et APT

456

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.

457

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 fait en modifiant les préférences d'APT pinning dans le système live − voir APT pinning pour plus d'informations.

458

8.4 Configuration d'APT pendant la construction

459

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`.

460

8.4.1 Choisir apt ou aptitude

461

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.

462

- `apt`: Avec cette méthode, si un paquet manquant est indiqué, l'installation va échouer. C'est le réglage par défaut.

463

- `aptitude`: Avec cette méthode, si un paquet manquant est indiqué, l'installation va réussir.

464

8.4.2 Utilisation d'un proxy avec APT

465

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

466

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

467

8.4.3 Régler APT pour économiser de l'espace

468

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.

469

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

470

$ lb config --apt-indices false

471

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.

472

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:

473

$ lb config --apt-recommends false

474

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 recommandations à 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.

475

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.

476

8.4.4 Passer des options à apt ou aptitude

477

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`:

478

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

479

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.

480

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.

481

8.4.5 APT pinning

482

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`.

483

Imaginons que vous voulez construire un système live buster 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, buster. Ce qui suit devrait accomplir cela:

484

$ 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

485

Une priorité pin négative empêchera l'installation d'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`:

486

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