|
|
|
|
|
|
|
|
|
|
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.
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 trixie pour la version de live-build dans trixie. 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 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.
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 paramétrer --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.
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.
$ 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://debian-live.alioth.debian.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.
You should also put the ASCII-armored GPG key used to sign the repository into config/archives/your-repository.key.{binary,chroot} files.
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/.
Similarly, if you need custom APT_AUTH.CONF(5) authentication configuration, this can be placed in config/archives/your-repository.auth.{binary,chroot} files and will be automatically added to your live system's /etc/apt/auth.conf.d/ directory
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
This supersedes the older predefined list method supported in live-build 2.x. Unlike predefined lists, task metapackages are not specific to the Live System project. Instead, they are maintained by specialist working groups within the distribution and therefore reflect the consensus of each group about which packages best serve the needs of the intended users. They also cover a much broader range of use cases than the predefined lists they replace.
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.
The packages in the .list.chroot_install list are present both in the live system and in the installed system.
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://deb.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é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.
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.
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 fait 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.
One commonly required APT configuration is to deal with building an image behind a proxy. You may specify your APT proxy with the --apt-http-proxy option as needed, e.g.
$ 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
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.
Two packages which you most probably will want to add again are:
$ lb config --apt-recommends false
$ echo "user-setup sudo" > config/package-lists/recommends.list.chroot
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.
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 trixie 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, trixie. 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 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:
Package: gnome-keyring
Pin: version *
Pin-Priority: -1
|
|
|