DNF kann einen Abhängigkeitsplan nicht erfüllen · Linux Fix Lab

Symptome und Geltungsbereich

DNF meldet keinen Anbieter einer benötigten Fähigkeit.
Ein Anbieter existiert, verträgt sich aber nicht mit dem installierten Paketstand.

Betroffene Umgebung

RPM-System mit DNF5; DNF4 nutzt ähnliche Konzepte mit teils anderen Optionen. Cache-Abfragen können alte Quellmetadaten zeigen.

Erkennbare Meldungen (synthetische Beispiele)

 - nothing provides libexample.so.3()(64bit) needed by example-app-2.0-1.x86_64 from vendor-repo

Aktive Quellen, Release und Architektur prüfen; diese Formulierung kommt auch bei anderen libsolv-Paketmanagern vor.

 - package example-app-2.0-1.x86_64 requires example-lib >= 3, but none of the providers can be installed

Nachfolgende Konflikte und Vorgaben lesen; ein vorhandener Anbieter unterscheidet sich von einem fehlenden Quellpaket.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

Eine nötige Quelle kann deaktiviert sein, dieses Release nicht anbieten oder nach Architektur/Version gefiltert werden.
Drittanbieter- oder teilweise aktualisierte Pakete können eine unpassende Abhängigkeitsversion verlangen.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

PACKAGE_NAME durch das installierte vom Solver genannte Paket ersetzen; liest RPM-Anforderungen ohne Transaktion.

rpm -q --requires PACKAGE_NAME

Ergebnis einordnen: Konkrete Fähigkeit, Soname und Versionsausdruck vergleichen. Ein Paketname ist nicht immer die vom Solver benötigte Abhängigkeit.

Prüfschritt 2

CAPABILITY durch die genaue Solver-Anforderung ersetzen; Klammern oder Vergleichsoperatoren weiter für die Shell quotieren. Liest nur gespeicherte Metadaten.

dnf5 --cacheonly repoquery --whatprovides 'CAPABILITY'

Ergebnis einordnen: Kein Treffer kann keinen Cache-Anbieter oder fehlenden/alten Cache bedeuten; er beweist kein fehlendes aktuelles Anbieterpaket. Release und Architektur vergleichen.

Nächste Schritte nach Befund

Die verantwortliche Quelle oder Paketversion korrigieren

Wenn das Paket aus einer Quelle für ein anderes OS-Release stammt, Quellkonfiguration sichern und unterstützte Release-Quelle oder Paketversion des Betreuers verwenden. Metadaten erneuern, die Transaktion mit --assumeno vorprüfen und erst nach Prüfung von Austausch und Entfernung anwenden.

Vorsicht: Keine beliebigen RPMs eines anderen Releases installieren oder --allowerasing ohne Prüfung jeder vorgeschlagenen Entfernung nutzen.

Wiederherstellung / Rücknahme: Gesicherte Quelle und zusammenhängenden Snapshot vor der Transaktion herstellen; nur die Quelldatei zurückzusetzen nimmt installierte Versionswechsel nicht zurück.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Einen geprüften betroffenen Paketstand synchronisieren

Wenn Quellen stimmen, aber installierte Versionen vom unterstützten Paketstand der Repositories abweichen, dnf5 --assumeno distro-sync PACKAGE_NAME für das betroffene Paket vorprüfen. Abhängigkeitstransaktion samt Downgrades vor administrativer Anwendung ohne automatische Zustimmung prüfen.

Vorsicht: Distro-sync kann Pakete zurückstufen; Datenmigrationen können unumkehrbar sein. skip-broken nicht zum Verbergen offener Abhängigkeiten nutzen.

Wiederherstellung / Rücknahme: Bei inkompatiblem Downgrade gesicherte Anwendungsdaten/-konfiguration und zusammenhängenden Snapshot herstellen; history undo hängt von Paketverfügbarkeit ab und ist nicht garantiert.