Au risque de répéter, ou reformuler, il n’est pas nécessaire de tripatouiller les fichiers de configuration police pour changer la police Monospace de l’environnement utilisateur. Ça ne peut faire que des sacs de noeuds pour la suite, entre les fichiers police système + user ‹ .conf ›, et les fichiers de configurations gnome ou KDE (~/.config/kdeglobals pour KDE).
Lorsque « Monospace » (appellation générique), qui appelle par défaut la police définie par le système, est remplacé par un nom de police explicite dans environment user, le réglage user est traité en priorité, et un changement de police système par défaut n’a aucun effet.
Démonstration: ma police Monospace est réglée sur ‹ Liberation Sans Mono ›.
Je viens de migrer de fontconfig/fontconfig-config 2.13.1-4.5 vers 2.14.1-3 (testing/sid):
→ aucune modification observée, bien que la police monospace système par défaut soit « Noto Sans Mono » (2.14.1-3):
/usr/share/fontconfig/conf.avail/60-latin.conf
<alias>
<family>monospace</family>
<prefer>
<family>Noto Sans Mono</family>
<family>DejaVu Sans Mono</family>
<family>Inconsolata</family>
<family>Andale Mono</family>
<family>Courier New</family>
<family>Cumberland AMT</family>
<family>Luxi Mono</family>
<family>Nimbus Mono L</family>
<family>Nimbus Mono</family>
<family>Nimbus Mono PS</family>
<family>Courier</family>
</prefer>
</alias>
Pour que la modification de configuration police dans l’interface graphique prévu à cet effet soit prise en compte, il faut soit fermer/réouvrir la session utiliateur, ou fermer/réouvrir l’application concernée.
Pas la peine de s’énerver pour rien, pas de bug, juste un peu d’attention lorsqu’on utilise une version testing, donc non stable.