SafeITExperts

SafeITExperts

Your expert guide to cybersecurity and digital privacy. Security hardening for all platforms : Windows, macOS, Linux, and Android. Solutions aligned standards : NIST and ANSSI for comprehensive digital protection.


Tutoriel 2025 : Installer KDE Unstable Plasma sur Tumbleweed

Publié par Marc sur 11 Septembre 2025, 08:30am

Catégories : #KDE Unstable Plasma, #openSUSE Tumbleweed, #Zypper, #rolling release

Tutoriel 2025 : Installer KDE Unstable Plasma sur Tumbleweed
Tutoriel 2026 : Installer KDE Unstable Plasma sur openSUSE Tumbleweed | SafeITExperts
Mode sombre
Rechercher
Menu

Installer KDE Unstable Plasma sur openSUSE Tumbleweed

🚀 Guide pratique 2026 — Vendor stickiness, priorités, commandes avancées
21 février 2026SafeITExpertsLecture : 30 minNiveau : Avancé
🎨 KDE Plasma🐧 Tumbleweed🦎 Zypper🔓 Vendor Stickiness⚡ Unstable📦 Btrfs/Snapper
📖
Introduction

🎯 Présentation

Vous voulez tester les dernières avancées de KDE Plasma sur votre Tumbleweed ? Ce guide vous montre une méthode qui fonctionne, utilisée au quotidien sur une machine de production.

Pas LA vérité absolue

La communauté openSUSE est riche d'expériences diverses. Certains préfèrent une priorité plus basse (75) pour un basculement complet, d'autres n'ajoutent que certains dépôts. Ce guide vous présente une méthode éprouvée – celle utilisée au quotidien – avec ses ingrédients, ses avantages et ses limites.

🎯 Objectif
Installer dépôts KDE Unstable sur Tumbleweed
⏱️ Durée
15–20 minutes
🔧 Niveau
Avancé
💾 Prérequis
Tumbleweed à jour, snapshot Btrfs récent

💻 Configuration de départ (exemple réel)

inxi -F – Snapshot février 2026
# Configuration de départ (exemple réel)
Operating System: openSUSE Tumbleweed 20260217
KDE Plasma Version: 6.6.0
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.2
Kernel Version: 6.19.2-1-default (64-bit)
⚙️
Comprendre Zypper en 2 minutes

🧩 Les trois mécanismes fondamentaux

Avant d'ajouter des dépôts, il faut saisir trois mécanismes : le vendor, la version et la priorité.

RègleExplication
🏷️ VendorChaque vendor a un dépôt, chaque dépôt a une priorité et des paquets
📦 VersionChaque version a un paquet, chaque paquet a un fournisseur, chaque fournisseur a un dépôt
⚖️ PrioritéChaque priorité est associée à un dépôt, chaque dépôt contient des paquets d'un fournisseur

🏷️ Vendor stickiness & mécanismes de Zypper

Trois niveaux permettent de contrôler le changement de fournisseur (vendor) dans Zypper. Du plus global au plus ponctuel :

NiveauConditionEffet sur zypper dup
🌍 Global/etc/zypp/zypp.conf
solver.allowVendorChange = true
Désactive totalement la protection vendor stickiness. zypper dup autorise automatiquement tous les changements de vendor.
🔗 Équivalence/etc/zypp/vendors.d/*.confDéclare des vendors comme équivalents (ex: openSUSE = obs://KDE:Unstable:Frameworks). Zypper les traite comme interchangeables.
🎯 Ponctuelzypper dup --allow-vendor-changeAutorise le changement de vendor uniquement pour cette exécution. Le prochain dup revient au comportement par défaut.
Trois points clés à retenir

1. Vendor stickiness : Zypper refuse par défaut tout changement de vendor, même pour une version plus récente. Un paquet avec vendor différent est ignoré dans dup simple, sauf si autorisation (--allow-vendor-change ou équivalence déclarée).

2. Priorités : Plus le chiffre est petit, plus la priorité est haute. Les priorités n'interviennent qu'à version égale et vendor autorisé.

3. --from <repo> : Force l'utilisation exclusive d'un dépôt pour la mise à jour, indépendamment des priorités ou du vendor.

✅ Tableau : priorité, version, vendor et comportement

PrioRepoVersiondup seul--allow-vendor--from
70Packman7.0.2
80home:pallaswept6.1.1
99repo-oss7.0.2
99repo-non-oss7.0.1
110home:Dead_Man6.0.0
120KDE:Frameworks57.0.2
Règle fondamentale

Le vendor prime sur la priorité. La priorité n'intervient qu'à vendor autorisé et version égale. Un dépôt avec priorité 70 mais vendor différent sera ignoré par dup tant que vous n'utilisez pas --allow-vendor-change ou une équivalence déclarée dans vendors.d.

📥
Préparation et ajout des dépôts KDE Unstable

🔧 Préparation du système (avant ajout des dépôts)

Avertissement officiel openSUSE

"Do not mix stable with unstable repositories. Doing so is not supported and is prone to put your system in an inconsistent state."SDB:KDE repositories

Voici les commandes à exécuter dans l'ordre pour préparer votre Tumbleweed.

CommandeRôleQuand l'utiliser
sudo zypper shellEntrer en mode interactif ZypperOptionnel, permet d'enchaîner plusieurs commandes
sudo zypper clean -aNettoyer tous les cachesAvant un rafraîchissement pour éviter les problèmes de cache
sudo zypper refRafraîchir la liste des paquetsAprès nettoyage ou avant une mise à jour
zypper packages --orphanedLister les paquets orphelinsPour identifier les paquets à désinstaller manuellement
zypper packages --recommendedLister les paquets recommandés non installésPour choisir ceux que vous souhaitez installer
sudo zypper dupMise à jour distributive complèteMet à jour tout le système vers les dernières versions stables
sudo systemctl rebootRedémarrer le systèmeNécessaire si le noyau ou des services critiques ont été mis à jour
Préparation complète via shell Zypper
$sudo zypper shell
zypper>clean -a
zypper>ref
zypper>packages --orphaned
zypper>packages --recommended
zypper>dup
zypper>exit
$sudo systemctl reboot

📥 Ajout des dépôts KDE Unstable

Une fois le système préparé et à jour, vous pouvez ajouter les dépôts KDE Unstable avec la priorité de votre choix.

Option A : priorité 75 (approche officielle)

Dépôts KDE Unstable — priorité 75
$sudo zypper ar -cfp 75 https://download.opensuse.org/repositories/KDE:/Unstable:/Qt/openSUSE_Tumbleweed/ KDE-Unstable-Qt
$sudo zypper ar -cfp 75 https://download.opensuse.org/repositories/KDE:/Unstable:/Frameworks/openSUSE_Factory/ KDE-Unstable-Frameworks
$sudo zypper ar -cfp 75 https://download.opensuse.org/repositories/KDE:/Unstable:/Applications/KDE_Unstable_Frameworks_openSUSE_Factory/ KDE-Unstable-Applications
$sudo zypper ar -cfp 75 https://download.opensuse.org/repositories/KDE:/Unstable:/Extra/KDE_Unstable_Frameworks_openSUSE_Factory/ KDE-Unstable-Extra

Option B : priorité 120 (approche sélective de ce guide)

Dépôts KDE Unstable — priorité 120
$sudo zypper ar -cfp 120 https://download.opensuse.org/repositories/KDE:/Unstable:/Qt/openSUSE_Tumbleweed/ KDE-Unstable-Qt
$sudo zypper ar -cfp 120 https://download.opensuse.org/repositories/KDE:/Unstable:/Frameworks/openSUSE_Factory/ KDE-Unstable-Frameworks
$sudo zypper ar -cfp 120 https://download.opensuse.org/repositories/KDE:/Unstable:/Applications/KDE_Unstable_Frameworks_openSUSE_Factory/ KDE-Unstable-Applications
$sudo zypper ar -cfp 120 https://download.opensuse.org/repositories/KDE:/Unstable:/Extra/KDE_Unstable_Frameworks_openSUSE_Factory/ KDE-Unstable-Extra

Signification des options -cfp

OptionSignificationEffet
-cActiver le cache localLes métadonnées sont conservées sur disque pour un accès plus rapide
-fAuto-refreshZypper rafraîchit automatiquement le dépôt à chaque opération
-p <priorité>Fixer la prioritéPlus le chiffre est petit, plus la priorité est forte

✅ Vérification de l'ajout

Vérification des dépôts KDE Unstable
# Nettoyage préventif (optionnel)
$sudo zypper clean -a
# Rafraîchissement
$sudo zypper ref
# Vérifier les priorités
$zypper lr -p | grep KDE-Unstable

Résultat attendu (exemple pour priorité 120) :

 2 | KDE-Unstable-Applications       | 120
 3 | KDE-Unstable-Extra              | 120
 4 | KDE-Unstable-Frameworks         | 120
 5 | KDE-Unstable-Qt                 | 120
🚀
Première mise à jour : basculer vers KDE Unstable
Rappel sur les snapshots

Par défaut, snapper crée automatiquement un snapshot après un zypper dup si des modifications ont été appliquées. Cependant, si vous voulez garantir un point de retour avant toute modification, créez-en un manuellement :

Créer un snapshot préventif
$sudo snapper create --description "Avant mise à jour KDE Unstable"

🏁 Méthode 1 : approche officielle (priorité 75)

Cette méthode correspond à la configuration recommandée par le wiki openSUSE pour les dépôts KDE:Unstable. Elle suppose que vous avez ajouté les dépôts avec une priorité de 75.

Méthode officielle — priorité 75
# 1. Rafraîchir les dépôts
$sudo zypper ref
# 2. Simuler avec changement de vendor
$sudo zypper dup --dry-run --allow-vendor-change --details
# 3. Exécuter la mise à jour (une fois avec --allow-vendor-change)
$sudo zypper dup --allow-vendor-change --details
# 4. Vérifier l'intégrité
$sudo zypper verify
# 5. Redémarrer
$sudo systemctl reboot
# 6. Vérifier la version de Plasma
$plasmashell --version
$zypper info plasma6-desktop | grep Repository

🛡️ Méthode 2 : approche sélective (priorité 120 — celle de ce guide)

Cette approche est plus prudente. Elle utilise une priorité faible (120) qui fait que les dépôts officiels (99) restent prioritaires à version égale. Mais attention : même sans --allow-vendor-change, un simple zypper dup peut déjà intégrer des paquets Unstable si leur version est strictement supérieure à la version stable.

Méthode sélective — priorité 120
# 1. Rafraîchir
$sudo zypper ref
# 2. Simuler la mise à jour simple
$sudo zypper dup --dry-run --details
# 3. Simuler avec changement de vendor pour comparer
$sudo zypper dup --dry-run --allow-vendor-change --details
# 4a. Mise à jour simple (paquets Unstable plus récents uniquement)
$sudo zypper dup
# 4b. OU mise à jour complète (tous les paquets Unstable disponibles)
$sudo zypper dup --allow-vendor-change --details
# 5. Vérifier l'intégrité
$sudo zypper verify
# 6. Nettoyage post-mise à jour
$zypper packages --orphaned
$sudo zypper inr

📌 Récapitulatif des deux méthodes

CritèreMéthode officielle (75)Méthode sélective (120, ce guide)
Priorité75 (plus forte)120 (plus faible)
À version égaleKDE Unstable gagneStable (99) gagne
Mise à jour simple (dup)Basculement completIntègre seulement les paquets Unstable de version > stable
Rôle --allow-vendor-changeNécessaire au premier basculementOutil de simulation et décision pour basculement complet
Niveau de risquePlus élevéMaîtrisé
Public viséTesteurs, développeursUtilisateurs avancés en production
🛠️
Gestion et maintenance avancée

🧩 Problèmes plausibles par dépôt KDE Unstable

Les dépôts Unstable sont instables par nature. Voici les problèmes réels documentés sur openSUSE Tumbleweed + KDE:Unstable :

🔴 Forte – risque élevé  |  🟠 Moyenne – risque modéré  |  🟢 Faible – cas particuliers

DépôtProblèmeDescriptionProbabilité
KDE:Unstable:QtRécupération de session Wayland défaillanteAprès upgrade, restauration des fenêtres cassée (positions, tailles)🔴
Plantage d'applications QMLplasma-systemmonitor, kinfocenter plantent au démarrage (régressions QtQuick)🟠
Rendu défectueux des icônes SVGIcônes SVG mal affichées après mise à jour Qt🟢
KDE:Unstable:FrameworksDépendances non satisfaites après dupkio/kconfig incompatibles avec bibliothèques système🔴
Thèmes GTK non appliquésApplications GTK ignorent Breeze après mise à jour Frameworks🟠
Réinitialisation partielle des paramètresWallpaper, raccourcis perdus après upgrade🟠
KDE:Unstable:ApplicationsPlantage de Dolphin sur dossiers réseau SMBDolphin crash à l'accès à des partages SMB (problème récurrent)🔴
Konsole ne conserve pas les profilsProfils personnalisés disparaissent après reboot🟠
Gwenview ne lit plus certaines imagesÉchec d'ouverture de JPEG/PNG (lié à SMB/ffmpeg)🟢
KDE:Unstable:ExtraWidget météo plante plasmashellCrash de la barre des tâches après ajout du widget météo🟠
KDE Connect instable / déconnexionsPerte de connexion aléatoire (firewall, réseau)🟠
Effets de bureau (cube, wobbly) inopérantsEffets KWin cassés après mise à jour🟢

🔧 La trousse à outils du pilote

Rafraîchir la liste des paquets

Rafraîchissement
$sudo zypper ref

Simuler une mise à jour sans rien changer

Simulation
$sudo zypper dup --dry-run
# Avec détails et vendor change :
$sudo zypper dup --dry-run --allow-vendor-change --details

Forcer la mise à jour depuis un dépôt spécifique

Mise à jour ciblée
# Toujours simuler d'abord
$sudo zypper dup --dry-run --details --from KDE-Unstable-Applications
# Puis exécuter si propre
$sudo zypper dup --from KDE-Unstable-Applications

Modifier la priorité d'un dépôt

Ajustement des priorités
$sudo zypper mr -p 110 KDE-Unstable-Applications
$sudo zypper mr -p 90 KDE-Unstable-Frameworks
$zypper lr -p | grep KDE-Unstable

Restaurer un snapshot système

Rollback Snapper
$sudo snapper list
$sudo snapper rollback <numero>

🐛 Bugs courants (février 2026)

Note

Ces solutions ont fonctionné sur des configurations spécifiques. En cas de problème, consultez d'abord les forums.

ProblèmeSymptômesSolution rapide
🖼️ Icônes Flatpak casséesIcônes incorrectes ou génériques (Ungoogled Chromium, OBS)Utiliser version RPM en attendant le correctif (Bug #516383)
🍔 Menu Kickoff capricieuxImpossible d'ajouter aux favoris, sous-menus qui disparaissentkbuildsycoca6 --incremental
⚙️ Paramètres réinitialisésRetour aux valeurs par défaut après mise à jourCopier les thèmes dans ~/.local/share/plasma/look-and-feel/
🔗 Conflits de dépendanceszypper dup refuse de s'exécuter--solver-focus=update --force-resolution (dernier recours) ou attendre
💥 Système casséDémarrage impossible ou session KDE ne se lance passudo snapper rollback <numero>
🧊 Freezes au loginSystème gèle après login KDEBasculer sur GNOME temporairement
Règle d'or

Toujours avoir un snapshot récent avant toute mise à jour majeure.

Créer un snapshot avant mise à jour
$sudo snapper list
$sudo snapper create --description "Avant mise à jour KDE"
🏆
Bonnes pratiques & Synthèse

📊 Comparaison des approches

🔴
Tout Unstable
Priorité 75
Basculement complet
Testeurs, développeurs
🟢
Sélective (ce guide)
Priorité 120
Unstable pour les nouveautés
Utilisateurs avancés prod.
🟡
Hybride
Priorité 90–100
Mix selon les cas
Expérimentateurs
Comment choisir ?

Approche 75 : si vous voulez être en première ligne, prêt à gérer des régressions fréquentes et contribuer aux retours upstream.

Approche 120 (ce guide) : si vous utilisez Tumbleweed en production, que vous voulez profiter des nouveautés sans mettre en péril la stabilité quotidienne.

Approche hybride (90-100) : terrain intermédiaire — par exemple, donner une priorité légèrement plus forte aux Frameworks qu'aux Applications.

Quelle que soit l'approche, le vendor prime toujours sur la priorité.

✅ Les bons réflexes

ActionPourquoi ?
Toujours simuler avec --dry-runAnticiper conflits, changements de vendor, paquets supprimés
Comprendre le vendor stickinessPremier filtre avant la priorité
Utiliser --allow-vendor-change avec parcimonieN'autoriser que quand vous voulez vraiment Unstable
Avoir un snapshot récentSnapper = parachute pour revenir en arrière
Surveiller les forums avant grosses mises à jourLa communauté remonte les bugs rapidement
Vérifier les priorités avec zypper lr -pConfirmer que vos réglages sont pris en compte
Privilégier --detailsVoir sauts de version et changements de vendor
Rafraîchir les dépôts avec zypper refTravailler avec les métadonnées les plus récentes

❌ Les erreurs à éviter

ActionConséquence
Faire dup sans simulationCasser le système sans prévoir
Laisser --allow-vendor-change en permanenceDépôts tiers indésirables remplacent des paquets
Mettre à jour sans snapshotAucun point de retour fiable
Ignorer les avertissements de conflitForcer mène à un système inconsistant
Mélanger priorités sans comprendre le vendorUne priorité forte ne suffit pas sans vendor autorisé
Négliger le nettoyage post-màjPaquets orphelins et caches encombrent

🔗 Ressources et liens utiles

RessourceDescriptionLien
Forums openSUSE KDESupport communautaireforums.opensuse.org
KDE DiscussDiscussions sur les évolutionsdiscuss.kde.org
OBS KDE UnstableÉtat des dépôtsbuild.opensuse.org
Bugzilla KDESuivi des bugs upstreambugs.kde.org
Bugzilla openSUSEProblèmes de packagingbugzilla.opensuse.org
Doc vendor changeDocumentation officielleopensuse.org

📖 Lectures complémentaires SafeITExperts

ArticleContenu
Kernels SUSE & Flavours – Guide CompletLes variantes du noyau Linux sur SUSE : default, rt, azure, xen…
Zypper openSUSE : Guide Complet 2025Toutes les commandes Zypper, gestion paquets et dépôts
Distributions Linux 2025 : Analyse CritiqueComparaison des distributions Linux out of the box
Wayland 2026 : L'Ère Post-X11 pour LinuxTransition X11 → Wayland, compatibilité et migration
Conclusion

Ce guide vous a présenté une méthode éprouvée pour installer KDE Unstable sur Tumbleweed. Elle n'est pas la seule, mais elle a l'avantage d'être sélective et prudente.

Prêt à tester ? Lancez-vous, mais n'oubliez pas : snapshots, simulations, et veille active sont vos meilleurs alliés.

Une rolling release, ça se maintient. Vous devenez acteur de votre système, pas simple consommateur. C'est un choix, une philosophie, et aussi un plaisir pour ceux qui aiment comprendre et maîtriser.

Pour être informé des derniers articles, inscrivez vous :
Commenter cet article

Archives

Nous sommes sociaux !

Facebook X Bluesky Mastodon GitHub Reddit RSS

Articles récents