Bonsoir, Jérôme, au 2019-01-15 : > Le lundi 14 janvier 2019 à 21:26 +0100, Étienne Mollier a écrit : > > Toujours aussi naïvement, j'aurais donc tendance à penser que > > l'utilité de ce fichier n'est plus, en tout cas pour une > > installation basique, et que donc vous n'avez pas mal fait. > > > > Gardez tout de même le fichier à portée de main, des fois que... [...] > Ça m'étonnerait qu'il n'y ait pas eu une explication dans la mise a jour, et > un message a root.
Tout le problème est de savoir quand c'est apparu. Si ça se trouve, la transition s'est faite silencieusement, entre deux versions stables de Debian, en laissant les anciennes clés expirer dans le fichier trusted.gpg et en incluant les nouvelles dans le répertoire trusted.gpg.d/. La présence de références à Wheezy dans trusted.gpg.d/ laisse à penser qu'une telle transition aurait pu avoir lieu entre Debian 6 et 7, donc quelque part entre 2011 et 2013. À moins d'avoir raté quelque chose, aucune mention de la suppression du trusted.gpg n'est apparue dans les courriels envoyés à root. Confère /usr/share/doc/apt/NEWS.Debian.gz. Du côté de la distribution des paquets, les mécanismes de signature ont apparemment été mis en place fin 2003 avec, si ça se trouve, un support immédiat du fichier trusted.gpg et son homologue en .d. Une entrée probablement intéressante dans le changelog est apparue en 2014, qui laisserait à penser que les fichiers trusted.gpg apparaissaient automatiquement au moins jusqu'en Wheezy: Extrait de /usr/share/doc/apt/changelog.gz : > * only create new trusted.gpg if directory is writeable Les distributions Stretch et Buster n'ont pas ce fichier de clés, au sortir d'une installation fraîche. Pour Jessie, je ne sais plus. Ma perception de la chose est que /etc/apt/trusted.gpg est utilisable, modulo un peu de configuration vis-à-vis de l'utilisateur _apt, mais n'est pas, ou n'est plus, indispensable. À la lecture du manuel de apt-key(8), j'ai l'impression qu'il peut être utile lors de l'ajout de dépôts tiers. Jérôme, au 2019-01-15 : > Le principe des trucs.conf.d c'est de remplacer le fichier de config monobloc > truc.conf par des fichiers qui contiennent les blocs de configuration > nécessaires mis dans le dossier truc.conf.d/ ce qui est plus facile a gérer > pour les configurations dynamiques (au branchement d'un truc...) et évite de > tout charger inutilement. > > Dans ce cas le fichier monobloc de configuration statique est supprimé. > > On peut toujours le remettre ou le trouver dans certains cas, mais l'idée est > là. Par exemple xorg.conf = statique xorg.conf.d/* = dynamique (plug'n > play). C'est mieux de faire un xorg.conf.d/50-ma-souris-gamer.conf qui va se > charger au branchement de ce modèle de souris que de gérer de manière statique > tous les cas dans xorg.conf > > Pour GPG il ne s'agit pas de brancher une souris, mais la gestion dynamique a > son intérêt pour la gestion automatisée. C'est une bonne explication. :^) Pour illustrer le problème de maintenance : devoir ajouter ou retirer une directive au milieu d'un gros fichier monolithique est en moyenne beaucoup plus compliqué que d'effacer un fichier contenant uniquement la directive incriminée, en particulier quant il faut automatiser la chose pour un parc de machine, ou via un paquet. Voici un exemple tiré de la vie réelle : $ dpkg --search /etc/X11/Xsession.d/* dbus-user-session: /etc/X11/Xsession.d/20dbus_xdg-runtime libvdpau-va-gl1:amd64, libvdpau-va-gl1:i386: /etc/X11/Xsession.d/20vdpau-va-gl x11-common: /etc/X11/Xsession.d/20x11-common_process-args x11-common: /etc/X11/Xsession.d/30x11-common_xresources x11-common: /etc/X11/Xsession.d/35x11-common_xhost-local boinc-client: /etc/X11/Xsession.d/36x11-common_xhost-boinc x11-common: /etc/X11/Xsession.d/40x11-common_xsessionrc x11-common: /etc/X11/Xsession.d/50x11-common_determine-startup gpg-agent: /etc/X11/Xsession.d/90gpg-agent at-spi2-core: /etc/X11/Xsession.d/90qt-a11y x11-common: /etc/X11/Xsession.d/90x11-common_ssh-agent x11-common: /etc/X11/Xsession.d/99x11-common_start On voit que plein de paquet peuvent ajouter facilement leur petit morceau de configuration, juste avec une copie, au lieu de devoir tout gérer avec x11-common. Et si la purge d'un de ces paquets est effectuée, les risques de casser les sessions graphiques sont minimes, en comparaison avec une manipulation effectuée directement dans /etc/X11/Xsession. Évidemment, cela se fait au prix d'une inflation du nombre des fichiers de configuration. Amicalement, -- Étienne Mollier <etienne.moll...@mailoo.org>