Detected 2 file conflicts:

Feli · 1. September 2022

Hi @ all,

ich bekomme beim Aktualisieren in Tumbleweed Plasma folgende Konfkiktmeldung:

Code

Detected 2 file conflicts:


File /usr/i686-w64-mingw32/sys-root/mingw/bin/iconv.dll
from install of
mingw32-libwin_iconv-0.0.8-6.14.noarch (windows:mingw:win32)
conflicts with file from package
mingw32-win_iconv-dll-0.0.8-5.18.noarch (@System)


File /usr/i686-w64-mingw32/sys-root/mingw/bin/libiconv.dll
from install of
mingw32-libwin_iconv-0.0.8-6.14.noarch (windows:mingw:win32)
conflicts with file from package
mingw32-win_iconv-dll-0.0.8-5.18.noarch (@System)


File conflicts happen when two packages attempt to install files with the same name but different contents. If you continue, conflicting files will be replaced losing the previous content.
Continue? [yes/no] (no):

Alles anzeigen

Ich mache dann mit "y" weiter und die Aktualisierung läuft durch - im laufenden Betrieb bemerke ich keine Störung, trotzdem die Frage, wie löse ich das auf?

Grüße, Felix

Hidalgo · 1. September 2022

Wenn man seine Repositories (Software-Quellen) nicht auf das unbedingt Notwendige

beschränkt, dann können beim Aktualisieren unterschiedliche Pakete abgerufen werden

die die selbe Datei dem Namen nach enthalten und sich deshalb dem Aktualisierungsprozess

aufdrängen. Diese Dateien haben zwar den selben Namen, aber einen unterschiedlichen

Entwicklungsstand und nun entsteht der Konflikt und die entsprechende Nachfrage.

(dieser Prozess kann schließlich nicht wissen was der User braucht und mit seinem System will)

So etwas ist nicht gewollt, nicht schön, aber Linux-Typisch, da Entwicklungen an diesem

System weltumspannend stattfinden und ein 100%iger Abgleich nicht immer gewährleistet sein

kann.

Demgegenüber arbeitet an Windows nur Microsoft bzw. hält die Hand vor Veröffentlichungen

von "Zu-Entwicklern".

Soweit zum Verständnis.

Damit so etwas gar nicht auftritt, gibt "auch" die OpenSuSE-Distri Empfehlungen, welche

Repositories man verwenden sollte, denn ein "zuviel" ist schädlich (aus genannten Gründen).

So ist nämlich gewährleistet, das jedes Paket / jede Datei nur einmal vorkommt.

Soviel zur Auflösung des Problems generell.

Akut hast Du es ja schon durchgeführt, d.h.

unterschiedliche Dateien wurden nun ersetzt

durch die aktuellste, die in deinen Repos enthalten ist.

Falls Du Dir nicht sicher bist, ob Dein System nun konfliktfrei funktioniert, kannst Du

z.B. in Yast gehen, dort in Software installieren oder löschen gehen und dann dein komplettes

System auf Abhängigkeitskonflikte überprüfen lassen. Geht Ruckzuck.

Das geht auch in der Konsole ohne Yast. Bitte selbst 'raussuchen.

Generell versucht ein Linux-System Redundanzen zu vermeiden, was

durch ein inkonsequentes Repo-Überangebot leider unterlaufen werden kann.

Auch welche Repos Du brauchst und welche überflüssig sind, auch das ist für

OpenSuSE im Netz zu finden.

Feli · 2. September 2022

Heute bekomm ich diese Meldung

Code

File /usr/i686-w64-mingw32/sys-root/mingw/bin/iconv.dll
  from install of
     mingw32-libwin_iconv-0.0.8-6.15.noarch (windows:mingw:win32)
  conflicts with file from package
     mingw32-win_iconv-dll-0.0.8-5.18.noarch (@System)

File /usr/i686-w64-mingw32/sys-root/mingw/bin/libiconv.dll
  from install of
     mingw32-libwin_iconv-0.0.8-6.15.noarch (windows:mingw:win32)
  conflicts with file from package
     mingw32-win_iconv-dll-0.0.8-5.18.noarch (@System)

Alles anzeigen

und meine Repos sehen so aus

Code

:~> inxi -r
Repos:
  Active zypp repos in: /etc/zypp/repos.d/ftp.gwdg.de-openSUSE_Tumbleweed.repo
    1: ftp.gwdg.de-openSUSE_Tumbleweed ~ http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/
  Active zypp repos in: /etc/zypp/repos.d/https-download.opensuse.org-038de60d.repo
    1: https-download.opensuse.org-038de60d ~ https://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/
  Active zypp repos in: /etc/zypp/repos.d/https-download.opensuse.org-4d828564.repo
    1: https-download.opensuse.org-4d828564 ~ https://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_Tumbleweed/
  Active zypp repos in: /etc/zypp/repos.d/https-download.opensuse.org-fadaa9b8.repo
    1: https-download.opensuse.org-fadaa9b8 ~ https://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Tumbleweed/
  Active zypp repos in: /etc/zypp/repos.d/multimedia_proaudio.repo
    1: multimedia_proaudio ~ https://download.opensuse.org/repositories/multimedia:/proaudio/openSUSE_Tumbleweed/
  No active zypp repos in: /etc/zypp/repos.d/openSUSE-20220121-0.repo
  Active zypp repos in: /etc/zypp/repos.d/opensuse-guide.org-openSUSE_Tumbleweed.repo
    1: opensuse-guide.org-openSUSE_Tumbleweed ~ http://opensuse-guide.org/repo/openSUSE_Tumbleweed/
  Active zypp repos in: /etc/zypp/repos.d/packman.repo
    1: packman ~ https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/
  No active zypp repos in: /etc/zypp/repos.d/repo-debug.repo
  Active zypp repos in: /etc/zypp/repos.d/repo-non-oss.repo
    1: repo-non-oss ~ http://download.opensuse.org/tumbleweed/repo/non-oss/
  Active zypp repos in: /etc/zypp/repos.d/repo-oss.repo
    1: repo-oss ~ http://download.opensuse.org/tumbleweed/repo/oss/
  No active zypp repos in: /etc/zypp/repos.d/repo-source.repo
  Active zypp repos in: /etc/zypp/repos.d/repo-update.repo
    1: repo-update ~ http://download.opensuse.org/update/tumbleweed/

Alles anzeigen

Durch bestätigen mit "yes" werde ich den Konflikt jedenfalls nicht los, es läuft nur die Aktualisierung durch, beim nächsten mal kommt der Konflikt wieder - Yast sagt übrigens, dass es keine Probleme gibt, bringt mich also nicht weiter.

Frage: soll ich/kann ich einfach die beiden Dateien löschen? Und aus welchem Repo kommt der Fehler?

Code

zypper remove /usr/i686-w64-mingw32/sys-root/mingw/bin/iconv.dll

zypper remove /usr/i686-w64-mingw32/sys-root/mingw/bin/libiconv.dll

Kann ich das machen?

Sauerland · 2. September 2022

Poste:

Code

zypper if mingw32-win_iconv-dll

Hidalgo · 2. September 2022

In Yast kann man die ignorierten Abhängigkeitskonflikte in Menü "Extras" zurücksetzen

und dann diese neu prüfen. Manchmal ist da etwas im Verlaufsspeicher und wenn man

den nicht zurücksetzt, werden die eigentlichen Fehler ignoriert.

Das würde ich nochmal machen und falls das die erneute Prüfung dann einwandfrei

ist, ist Dein System auch in Ordnung in Bezug auf Abhängigkeiten.

Zu den Repos in Tumbleweed kann ich wegen des Leap-Systems

bei mir schlecht etwas sagen, aber

so wie ich das sehe - falls ich das richtig sehe - würde ich das

Code

/mingw:/win32

Repo zumindest deaktivieren und nur das 64er nutzen.

Im Hinterkopf habe ich, dass gleiche Dateiversionen in unterschiedlicher

Bit-Architektur sich ins Gehege kommen können.

Das da:

Code

zypper remove /usr/i686-w64-mingw32/sys-root/mingw/bin/iconv.dll

zypper remove /usr/i686-w64-mingw32/sys-root/mingw/bin/libiconv.dll

würde ich machen, wenn nach Abschalten des o.a Repos der Fehler

noch auftritt.

Vorher kannst Du diese beiden .dll-Dateien ja händisch ion Dein /home

sichern falls diese noch gebraucht werden sollten.

Feli · 3. September 2022

Zitat von Hidalgo
Zu den Repos in Tumbleweed kann ich wegen des Leap-Systems
bei mir schlecht etwas sagen, aber
so wie ich das sehe - falls ich das richtig sehe - würde ich das
Code
/mingw:/win32
Repo zumindest deaktivieren und nur das 64er nutzen.

ja, das kam mir schlüssig vor und ich hab das mal gemacht - es gab danach dann erst mal viel "Mecker" vom System - ob ich da immer richtig entschieden habe, das weiß ich noch nicht, aktuell läuft aber alles.

Hidalgo · 3. September 2022

Dass das System meckert, wenn diesem die Software eines

ganzen Repos "weggerissen wird", ist nicht zu vermeiden

und das sollte nicht verunsichern, bzw. da muss man durch.

Man kann sich vorstellen, dass ja Abhängigkeiten zwischen den

Dateien aus diesem Repo bestehen. Nehme ich z.B. nur eine Datei

"A" weg und es besteht eine Abhängigkeit mit einer Datei "B",

dann meckert natürlich Datei "B". Umgekehrt dasselbe.

Nehme ich nun aber beide Dateien weg, dann ist Ruhe und

auch das "Rest-System" ist ok. Abhängigkeiten bestehen nun nicht

mehr, bzw. lösen sich auf.

Bei solchen tiefgreifenden Änderungen des Systems ist die

Überprüfung auf Abhängigkeitskonflikte überfordert und der

User wird sich dann auch nicht verunsichern lassen müssen wenn

er weiß woran das liegt.

So gibt es immer Ausnahmen zur Regel - immer und überall.

Um bei mir etwaige Unsicherheiten trotzdem zu beseitigen und

sicher zu gehen, ob mein System nun konfliktfrei läuft, würde

ich im Terminal einfach mal ein

zypper update

durchführen - oder in Yast eine Online Aktualisierung durchführen.

Kommen dann keine Fehlermeldungen würde ich spätestens dann

davon ausgehen dass das System fehlerfrei ist. Ansonsten

Feli · 4. September 2022

Ein

Code

zypper dup

lief heute problemlos ohne Mecker oder Konfliktmeldungen durch - ich warte mal noch ein bisschen ab, aber das dürfte es gewesen sein.

Bleibt die Frage, wie das ins System kam - ich kann mir eigentlich nur vorstellen, dass es durch das ausführen von

Code

opi codecs

ins System gekommen ist - wäre das möglich?

Hidalgo · 4. September 2022

Meines Wissens bezieht sich "opi codecs"

auf das Packman-Repo und darum halte ich

es für unwahrscheinlich, dass das System

deshalb "unnötig belastet" wurde.

Feli · 4. September 2022

Und wie kann das ins System gekommen sein?

Wissentlich/vorsätzlich hab ich es nicht installiert - wo oder wie kann es dann passiert sein?

Detected 2 file conflicts:

KMail: Speicher-Problem

Hurl 6.0.0 erzeugt Werte dynamisch über Funktionen

Tumbleweed Update 27.11.2024

Ich habe mir meine .bashrc versaut und komme nicht mehr in mein Leap 15.1

Nitrux 3.8.0 verbessert Systemstart über OpenRC

Videofix

Franzel

erisso

allge

backtrop.gotten

Teilen