Fedora streicht Deepin-Pakete aus den Repositories

Fedora hat Ernst gemacht: Die Deepin-Desktop-Pakete sind aus den offiziellen Repositories verschwunden, und zwar vollständig. Was sich lange als schwelender Konflikt zwischen Paket-Pflege und Sicherheitsanspruch angedeutet hat, wurde am 19. Mai 2026 vom Fedora Engineering Steering Committee (FESCo) besiegelt. Sieben Stimmen dafür, keine Gegenstimme, keine Enthaltung. Ein klares Votum, das für eine Community, die sich sonst gerne in langen Diskussionsfäden verliert, ungewöhnlich eindeutig ausfiel.

Für alle, die Deepin bislang über die Standard-Repositories auf ihrem Fedora-System installiert hatten, ändert sich damit etwas Grundsätzliches. Die Pakete sind weg, Updates gibt es nicht mehr, und ein Wiedereinzug ist an Bedingungen gekoppelt, die kurzfristig kaum erfüllbar wirken. Fedora 45, die aktuelle Fall Release, wird ohne Deepin ausgeliefert. Wer die Desktop-Umgebung dennoch will, muss selbst Hand anlegen.

Der FESCo-Beschluss und seine Zeitleiste

Die Vorgeschichte ist kurz, aber deutlich. Am 5. Mai 2026 kontaktierte FESCo die Deepin-Maintainer und setzte eine Frist von vier Wochen für eine substanzielle Rückmeldung. Es ging um den Zustand der Pakete, um offene Sicherheitsfragen und um die Frage, ob das deepinde-SIG-Team überhaupt noch aktiv ist. Die Antwort blieb aus. Keine Stellungnahme, keine Roadmap, kein Lebenszeichen aus dem Projektumfeld, das die Bedenken hätte entkräften können.

Nach Ablauf der Frist tagte FESCo und beschloss den Rückzug aller Deepin-bezogenen Pakete. Im Protokoll findet sich die Formulierung, dass Release Engineering angewiesen wurde, die Pakete nicht ohne erneute, vollständige Review wieder freizugeben. Das ist kein Formalismus. Es bedeutet, dass eine Rückkehr in die Fedora-Repositories nur über einen kompletten Neuaufguss des Package-Review-Prozesses laufen kann, inklusive aktiver Maintainer, die für den Code auch tatsächlich verantwortlich zeichnen.

Wer die Fedora-Historie kennt, weiß, dass solche Retire-Entscheidungen nicht selten sind. Pakete werden ständig aussortiert, wenn Maintainer abspringen oder Software technisch veraltet. Ungewöhnlich ist hier eher der Umfang und die klare Kommunikation der Gründe. FESCo hat nicht einfach ein paar verwaiste RPMs aufgeräumt, sondern eine komplette Desktop-Umgebung aus dem Ökosystem entfernt.

Warum Deepin die Reißleine gezogen bekam

Die Begründung liest sich wie ein Lehrbuch für gescheiterte Open-Source-Governance. Zum einen die Sicherheitslage: Berichte sprechen von anhaltenden Problemen seit 2018, teils im Zusammenhang mit der Integration von Polkit und D-Bus in die Deepin-Desktop-Umgebung. Das sind keine Nebensächlichkeiten, sondern Kernkomponenten, über die Rechte im System vergeben werden. Wenn dort Schwachstellen unpatcht bleiben, betrifft das nicht nur Deepin-Nutzer, sondern potenziell das ganze System.

Wer sich mit Polkit-Regeln auskennt, weiß, wie heikel unsaubere Konfigurationen an dieser Stelle sind. Polkit steuert, welche Aktionen ein nicht-privilegierter Nutzer auslösen darf – vom Einhängen externer Datenträger bis hin zur Netzwerkänderung. Wenn eine Desktop-Umgebung eigene Polkit-Agents mitbringt und diese nicht sauber gegen die Systemrichtlinien abgegrenzt sind, entstehen privilege-escalation-Szenarien, die Angreifern lokale Rechteausweitung ermöglichen. Genau solche Muster wurden in Deepin-Komponenten wiederholt identifiziert, ohne dass upstream zeitnah reagierte.

Ähnlich verhält es sich mit der D-Bus-Integration. Deepin nutzt intensiv eigene D-Bus-Interfaces für die Kommunikation zwischen Desktop-Komponenten. Das ist technisch legitim, wird aber zum Problem, wenn D-Bus-Policy-Dateien zu großzügig formuliert sind oder wenn Interfaces暴露 werden, die gar nicht für den Systembus gedacht waren. In Kombination mit den bekannten FTBFS-Problemen (Failed To Build From Source) entstand so eine Situation, in der Pakete nicht nur Sicherheitslücken enthielten, sondern teilweise schon beim Bauen scheiterten und nur durch manuelle Workarounds überhaupt installierbar blieben.

Zum anderen der Wartungszustand. Die Pakete galten als weitgehend verwaist, mit Build-Fehlern und Installationsproblemen, die in Fedora-Terminologie als FTBFS und FTI geführt werden. Wer selbst schon einmal versucht hat, ein RPM-Spec-File aktuell zu halten, weiß, wie schnell sich technische Schulden aufbauen, wenn niemand mehr regelmäßig nachzieht. Bei Deepin kam laut den zitierten Berichten dazu, dass Standard-Packaging-Mechanismen umgangen wurden, was Reviewern die Arbeit zusätzlich erschwerte.

Der dritte Punkt ist der eigentliche Sargnagel: der komplette Ausfall der Kommunikation. Ein Sicherheitsproblem lässt sich beheben, wenn ein Projekt reagiert. Bleibt die Reaktion aus, hat ein Distributor kaum eine andere Wahl, als die Reißleine zu ziehen. Genau das ist bei Fedora passiert, nachdem die viermonatige… eigentlich vierwöchige Frist verstrichen war, ohne dass sich am Deepin-Ende irgendetwas bewegt hätte.

openSUSE war schon früher dran

Wer den Fedora-Schritt isoliert betrachtet, verpasst den eigentlichen Trend. openSUSE hat die Deepin-Pakete bereits rund ein Jahr zuvor entfernt, aus praktisch identischen Gründen: Sicherheitsbedenken und Verstöße gegen etablierte Packaging-Regeln. Fedora zog damit nicht als Vorreiter nach, sondern als zweite große Distribution, die zu demselben Schluss kam.

Das ist bemerkenswert, weil openSUSE und Fedora technisch und kulturell recht unterschiedlich ticken, aber bei der Bewertung von Deepin zu nahezu identischen Ergebnissen kamen. Zwei unabhängige Review-Prozesse, ein übereinstimmendes Urteil. Das spricht eher für ein strukturelles Problem auf Deepin-Seite als für distributionsspezifische Eigenheiten oder überzogene Ansprüche einzelner Reviewer.

Ich halte diesen Gleichlauf für den eigentlich relevanten Punkt der ganzen Geschichte. Eine einzelne Distribution, die ein Paket rauswirft, ist Alltag. Zwei große, unabhängig voneinander agierende Communitys, die zum selben Schluss kommen, ist ein Signal. Und Signale dieser Art werden in der Linux-Welt meist ernster genommen als einzelne Community-Entscheidungen.

Die Maintainer-Lücke: Wenn Upstream nicht liefert

Der Deepin-Fall illustriert ein systemisches Problem, das weit über diese eine Desktop-Umgebung hinausgeht. In der Linux-Distributionslandschaft existiert eine oft unsichtbare Arbeitsteilung: Upstream-Projekte entwickeln die Software, Distributions-Maintainer verpacken sie und halten sie aktuell. Dieses Modell funktioniert nur, wenn beide Seiten kommunizieren. Wenn Upstream auf Anfragen nicht reagiert, Sicherheitsberichte ignoriert oder Release-Zyklen nicht einhält, stehen Distributions-Maintainer vor einem Dilemma.

Sie können die Pakete im Alleingang patchen – das skaliert aber nicht, besonders nicht bei einer so umfangreichen Desktop-Umgebung wie Deepin mit hunderten Abhängigkeiten. Oder sie können die Pakete als unmaintained markieren und hoffen, dass Nutzer das Risiko selbst einschätzen. Fedora hat sich für die dritte Option entschieden: konsequente Entfernung. Das ist die ehrlichste Variante, weil sie das Problem nicht verschleiert, sondern offenlegt.

Für andere Projekte sollte das als Warnung dienen. Wer seine Software in großen Distributionen vertreten sehen will, muss erreichbar sein. Das bedeutet nicht, dass jedes kleine Projekt einen dedizierten Security-Officer braucht. Aber es bedeutet, dass Mailinglisten gelesen werden, dass auf Bug-Reports innerhalb angemessener Fristen reagiert wird, und dass Sicherheitslücken ernst genommen werden, bevor ein Distributor sie öffentlich eskaliert. Deepin hat an allen drei Fronten versagt.

Was das für Fedora-Nutzer praktisch bedeutet

Wer aktuell ein Fedora-System mit installiertem Deepin betreibt, muss zunächst keine Panik schieben. Bestehende Installationen laufen weiter. Das eigentliche Risiko liegt in der Zukunft: Ohne Anbindung an die offiziellen Repositories gibt es keine Sicherheitsupdates mehr, und mit jedem neuen Fedora-Release steigt die Wahrscheinlichkeit von Inkompatibilitäten zwischen Deepin-Komponenten und dem restlichen System.

Technisch bleiben zwei Wege offen. Der erste: Deepin aus dem Quellcode selbst kompilieren. Das ist machbar, aber aufwendig, und man übernimmt damit faktisch die Rolle des Maintainers, die FESCo dem Projekt gerade entzogen hat, samt aller Verantwortung für Sicherheitspatches. Der zweite Weg führt über Drittanbieter-Repositories, die man per dnf config-manager --add-repo einbinden kann. Auch das funktioniert technisch, widerspricht aber genau der Sicherheitslinie, die Fedora mit dem Retire-Beschluss durchsetzen wollte. Wer diesen Weg geht, sollte sich bewusst sein, dass die Qualitätskontrolle dann komplett in fremder Hand liegt, ohne die Reviewmechanismen, die Fedora-Pakete sonst durchlaufen.

Realistischer ist für die meisten Nutzer der Wechsel auf eine der etablierten Desktop-Umgebungen. GNOME und KDE Plasma sind die naheliegenden Kandidaten, weil sie in Fedora ohnehin am besten gepflegt und am tiefsten integriert sind. Wer es klassischer mag, findet mit Cinnamon oder Xfce Alternativen, die zwar optisch weniger verspielt sind als Deepin, dafür aber eine deutlich robustere Update-Historie vorweisen können. Ein offizieller Deepin-Spin für Fedora, wie es ihn für andere Desktop-Umgebungen gibt, wird durch die aktuelle Entwicklung noch unwahrscheinlicher, als er es ohnehin schon war.

Der größere Trend: Distributionen ziehen die Sicherheitsschraube an

Der Deepin-Fall fügt sich in ein Muster, das sich in den letzten Jahren bei mehreren großen Distributionen beobachten lässt. Paketreviews werden strenger, Toleranz für unmaintained Software sinkt, und Kommunikationsverweigerung von Upstream-Projekten wird nicht mehr klein beigebügelt, sondern konsequent sanktioniert. Für Nutzer, die sich an lockere Aufnahme-Standards älterer Distributionsjahre gewöhnt haben, mag das nach Bürokratie riechen. Für die Sicherheit des Gesamtsystems ist es aber eher überfällig als übertrieben.

Fedora hat in den vergangenen Releases ohnehin gezeigt, dass die Distribution technische Modernisierung und Sicherheitsanspruch über Kompatibilität mit exotischer Software stellt, das war zuletzt schon bei der Diskussion um Fedora 44 und dem Verhältnis zu Red Hat sichtbar. Die Deepin-Entscheidung passt in dieses Bild: Wer nicht liefert, fliegt raus, unabhängig davon, wie hübsch die Desktop-Umgebung aussieht oder wie treu ihre Nutzerbasis ist.

Interessant wird es, wenn man den Blick auf die Paketqualität in Repositories generell weitet. Ob es um Kernel-Patches, um Container-Ökosysteme oder um Desktop-Umgebungen geht: Die Bereitschaft, verwaiste oder riskante Komponenten aus offiziellen Quellen zu entfernen, statt sie aus Rücksicht auf Nutzerzahlen zu dulden, nimmt spürbar zu. Das ist im Kern eine gute Nachricht für alle, die produktive Systeme auf Fedora oder vergleichbaren Distributionen betreiben, auch wenn es im Einzelfall unbequem ist.

Kein politisches Statement, sondern Paketpflege

In Foren und Kommentarspalten kursiert schnell die These, hinter der Entscheidung stecke ein politisches Motiv gegen eine chinesische Desktop-Umgebung. Diese Lesart lässt sich anhand der öffentlich dokumentierten FESCo-Begründung nicht stützen. Die Argumentation dreht sich ausschließlich um Sicherheitslücken, Wartungszustand und die fehlende Reaktion der Maintainer, nicht um Herkunft oder geopolitische Erwägungen. Wer hier eine Verschwörung sucht, konstruiert etwas, das die Faktenlage nicht trägt.

Das entlastet Deepin aber nicht von der eigentlichen Kritik. Ein Projekt, das über Jahre bekannte Sicherheitsprobleme nicht konsequent adressiert und auf direkte Anfragen einer großen Distribution schlicht nicht reagiert, hat ein strukturelles Problem, unabhängig davon, wo die Entwickler sitzen. ZDNet bringt es in seiner Analyse auf den Punkt: Die wiederholten Sicherheitsprobleme seien für eine der größten Distributionen schlicht eine Brücke zu weit gewesen. Das ist eine Einschätzung, keine belegte Tatsache, aber sie deckt sich mit dem, was aus dem FESCo-Protokoll hervorgeht.

Was Admins und Homelab-Betreiber jetzt tun sollten

Wer Deepin produktiv einsetzt, sollte den Vorfall als Anlass nehmen, die eigene Desktop-Strategie zu überdenken, statt einfach weiterzumachen und auf bessere Zeiten zu hoffen. Ein System ohne Sicherheitsupdates ist kein theoretisches Risiko, sondern ein sehr konkretes, besonders wenn es im Netzwerk steht und nicht isoliert im Testlabor läuft.

Praktisch heißt das: Bestand prüfen, betroffene Pakete identifizieren, und einen Migrationspfad zu GNOME oder KDE Plasma planen, bevor das nächste Fedora-Upgrade anstehen. Ein strukturiertes Vorgehen könnte so aussehen: Zunächst mit dnf list installed | grep deepin alle installierten Deepin-Pakete auflisten, dann persönliche Konfigurationsdateien sichern – insbesondere unter ~/.config/deepin/ und ~/.config/dconf/ –, und schließlich die Desktop-Umgebung wechseln, bevor man auf Fedora 46 aktualisiert.

Wer ohnehin regelmäßig zwischen Distributionen wechselt oder mehrere Systeme parallel betreibt, kann die Umstellung nutzen, um gleich zu evaluieren, welche Desktop-Umgebung für den eigenen Workflow am besten passt. KDE Plasma bietet Deepin-Nutzern vermutlich den sanftesten Übergang, weil die Konfigurierbarkeit und das visuelle Konzept ähnlich sind. GNOME erfordert eine stärkere Umgewöhnung, belohnt aber mit tighterer Systemintegration unter Fedora. ItsFOSS beschreibt den Fedora-Schritt treffend als vorläufiges Ende der Deepin-Ära auf dieser Distribution, zumindest solange sich keine neuen, aktiven Maintainer finden und die Pakete keine erneute Review durchlaufen.

Für alle, die aus Prinzip an Deepin festhalten wollen, bleibt der Weg über Drittanbieter-Repositories oder Eigenbau offen. Nur sollte man sich dabei nicht der Illusion hingeben, dass damit die Sicherheitslage besser wird. Sie verschiebt sich lediglich von der Fedora-Community auf die eigenen Schultern, ohne die Reviewmechanismen, die genau diese Probleme eigentlich hätten verhindern sollen.

Was bleibt?

Die Entfernung der Deepin-Pakete aus den Fedora-Repositories ist am Ende weniger eine Nachricht über eine einzelne Desktop-Umgebung als über den Zustand von Paketpflege in großen Linux-Distributionen generell. Zwei unabhängige Communitys, ein übereinstimmendes Urteil, eine klare Frist, die verstreichen durfte, ohne dass irgendjemand reagierte. Das ist selten so eindeutig, wie es in diesem Fall war.

Bleibt die Frage, ob Deepin aus diesem Vorfall lernt oder ob das Projekt weiter in der Nische verschwindet, in der es künftig nur noch über Eigenkompilierung oder inoffizielle Quellen erreichbar ist. Für Fedora-Nutzer, die jetzt vor der Wahl stehen, lohnt sich ein nüchterner Blick auf GNOME und KDE Plasma, bevor die nächste Aktualisierung anstehende Kompatibilitätsprobleme mit sich bringt, die sich hätten vermeiden lassen.