|
|
|
|
|
|
|
|
|
|
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.
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:
$ lb config --distribution sid
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:
$ lb config --archive-areas "main contrib non-free"
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 Live Systems 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.
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.
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.
$ lb config --mirror-bootstrap http://localhost/debian/ \
--mirror-chroot-security http://localhost/debian-security/
Le miroir chroot, indiqué avec --mirror-chroot, est par défaut la valeur de --mirror-bootstrap.
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 http.debian.net, 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.
$ lb config --mirror-binary http://mirror/debian/ \
--mirror-binary-security http://mirror/debian-security/ \
--mirror-binary-backports http://mirror/debian-backports/
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.
deb http://live-systems.org/ 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 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/.
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.
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 pour plus de détails.
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:
$ lb config
$ echo task-gnome-desktop > config/package-lists/desktop.list.chroot
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:
$ apt-cache search --names-only ^task-
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:
$ debtags search role::metapackage
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.
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.
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:
$ lb config
$ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot
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é:
#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 indiqué:
#if ARCHITECTURES i386 amd64
memtest86+
#endif
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:
#if ARCHIVE_AREAS contrib non-free
vrms
#endif
L'imbrication des conditions n'est pas prise en charge.
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.
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:
$ 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
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:
$ lb config --linux-packages linux-image-3.18.0-trunk
$ echo "deb http://ftp.debian.org/debian/ experimental main" > config/archives/experimental.list.chroot
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. 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.
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:
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:
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.
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:
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.
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.
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 pour plus d'informations.
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.
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.
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
$ lb config --apt-http-proxy http://proxy/
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:
$ lb config --apt-indices false
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:
$ lb config --apt-recommends false
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.
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:
$ lb config --apt-options "--yes -oAcquire::Check-Valid-Until=false"
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.
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 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:
$ 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
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:
Package: gnome-keyring
Pin: version *
Pin-Priority: -1