Linux und Ich

Blog über Ubuntu, Linux, Android und IT

archlinux-logo

Dateikonflikte bei Pacman-Updates in Arch Linux lösen

| 11 Kommentare

Eine der größten Stärken von Arch Linux ist die Aktualität der Software. So ist zum Beispiel GNOME 3.12 (hier die Release Notes) nur wenige Tage alt und schon heute trudelt die neue GNOME-Version in den Paketquellen von Arch ein. Unter Ubuntu müsste man jetzt mit PPAs hantieren oder eben warten bis Ubuntu 14.10 die nächste GNOME-Version mit ausliefert. Di Aktualität und Flexibilität von Arch Linux hat jedoch auch ihren Preis: Ab und an kommt es in der Paketverwaltung zu Konflikten, erst recht wenn man Pakete aus dem Arch User Repository (kurz AUR) installiert. Doch diese Problemchen lassen sich im Normalfall recht leicht ausbügeln.

Nur wenige Tage nach dem Release von GNOME 3.12 trudelt das Update bei Arch Linux ein.

Bei mir hing das GNOME-Update auf zwei Rechnern fest, die Installation brach mit unterschiedlichen Dateikonflikten ab. Von daher möchte ich diese Situation beispielhaft für “Instabilitäten” in Arch Linux nehmen, nach denen hier im Blog immer wieder mal gefragt wurde. Solche Konflikte entstehen dann, wenn Pakete Dateien ins Dateisystem schieben, wo andere Pakete gleichnamige Dateien ablegen möchten. Dies kam bei mir im Rahmen des GNOME-Updates auf zwei Rechnern vor, auf denen ich zuvor Pakete aus dem AUR installiert hatte.

$ sudo pacman -Syu
...
(162/162) Überprüfe Paket-Integrität [######################] 100%
(162/162) Lade Paket-Dateien [######################] 100%
(162/162) Prüfe auf Dateikonflikte [######################] 100%
Fehler: Konnte den Vorgang nicht durchführen (In Konflikt stehende Dateien)
gtksourceview3: /usr/share/gtksourceview-3.0/styles/solarized-dark.xml existiert im Dateisystem
gtksourceview3: /usr/share/gtksourceview-3.0/styles/solarized-light.xml existiert im Dateisystem
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.

Die Lösung dieses Problem ist nicht schwer, man muss sich nur ein wenig in den Paketmanager von Arch einarbeiten. Im ersten Schritt gilt es herauszufinden welches Paket die Datei /usr/share/gtksourceview-3.0/styles/solarized-dark.xml im System abgelegt hat und die Installation des überarbeiteten Pakets gtksourceview3 verhindert. Dazu kann man pacman mit der Option -Qo und dem vollen Pfad der problematischen Datei aufrufen, unter Debian/Ubuntu entspräche der Befehl dem Aufruf dpkg -S.

$ pacman -Qo /usr/share/gtksourceview-3.0/styles/solarized-light.xml
/usr/share/gtksourceview-3.0/styles/solarized-light.xml ist in gedit-solarized-git 20130705-1 enthalten

Der Schuldige ist somit schnell gefunden, gedit-solarized-git aus dem AUR belegt den Platz, den nun auch gtksourceview3 einnehmen möchte. Um das Problem zu beheben wirft man am besten das unwichtigere Paket — in dem Fall also gedit-solarized-git — vom Rechner. Konflikte mit Paketen aus den Main-Quellen sollte es eigentlich nie geben, da hier auf eine Abstimmung der Speicherorte geachtet wird, ansonsten wäre dies ein klarer Fehler im Paket und müsste von Arch behoben werden.

$ sudo pacman -Rc gedit-solarized-git

Nach der Deinstallation von gedit-solarized-git lief das große GNOME-Update bei mir jeweils reibungslos durch, sollten weitere solche Konflikte auftauchen, muss man sie eben auf dem selben Weg lösen. Schwierig ist das meist nicht, und auch der Zeitaufwand hält sich in Grenzen. Mit Ubuntu und den GNOME-PPAs hatte ich in der Vergangenheit deutlich mehr Ärger, als beim Update von GNOME 3.10 auf GNOME 3.12 in Arch.

Autor: Christoph

Hallo, ich bin Christoph -- Linux-User, Blogger und pragmatischer Fan freier Software. Wie Ihr ohne Zweifel bemerkt haben solltet schreibe ich hier über Linux im Allgemeinen, Ubuntu im Speziellen, sowie Android und andere Internet-Themen. Wenn du Freude an meinen Artikel gefunden haben solltest, dann kannst du mir über Facebook, Google+ oder Twitter oder natürlich dem Blog folgen.

11 Kommentare

  1. Konflikte dieser Art lassen sich unter Ubuntu genau so schnell lösen. Dort bekommt man sogar angezeigt, mit welchem Paket das zu installierende in Konflikt steht.

    • Vorsicht, er redet von einer Datei, das ist was anderes als ein Paket und bei Paketen ist häufig der Konflikt im jeweiligen Paket “hinterlegt”.

      Allerdings muss man auch sagen, dass sowas für ein Update bereits deutlich mehr Aufwand ist, als man bei einem Ubuntu in aller Regel haben wird.
      Entsprechend das unter “RR ist nicht wirklich schwerer” abzulegen, stimmt da nicht mehr.
      Nicht das etwas an RR falsch ist, aber jemand der ein “einmal installieren und vergessen”-System will zu Arch/Gentoo $andere_RR zu raten wäre da vollkommen verkehrt, nicht nur für die Person sondern auch für die Distri, jemand den man mit “ist genau so einfach” zu der Distri bewegt, wird äusserst enttäuscht sein und damit die Distri deutlich schlechter bewerten als sie ist.

      • Meine Arch-Artikel sollen auch nicht “Unbedarfte” in die Falle locken. Wer einmal installieren und sich dann zwei Jahre nicht mehr drum kümmern möchte, der ist bei anderen Distributionen besser aufgehoben als bei Arch, ganz klar.

        • naja da kann man unter KDE abhilfe schaffen, apper installieren, dann in settings einfach auf automatisch Updates entweder Sicherheit oder alle updates. Apper macht seine Arbeit fein im Hintergrund man bekommt immer ein Info Fenster kurz das dass System wieder uptodate ist und in der History von Apper sieht man was aktualisiert wurde.

          So haelt sich das System vorlaufend aktuell, das ist dann was fuer Leute die sich eben nicht drum kuemmern oder wie mich der Laptop mit ArchLinux zum arbeiten benutzt.

          Ich wuerde es begruessen nebenbei bemerkt wenn es endlich mal Hoster gibt die Archlinux als Servervariante anbieten.

      • Ich würde fast sagen, dass Arch weniger Probleme verursacht. Was genau ist denn das nervige an anderen Distris? Ich sehe da vor allem folgende Probleme:

        1. Viele proprietäre, nicht „perfekte“ OSS ist nicht in den offiziellen Repositories enthalten, so dass man dort mit irgendwelchen Drittrepositories basteln muss, die dann natürlich nicht super unterstützt sind oder Fehler verursachen.
        2. Irgendwann hat man unglaublich veraltete Software. Bei Systemsoftware (d.h. das Betriebssystem in engeren Sinn, insofern es das bei Linux überhaupt gibt) ist das natürlich recht egal, aber man will ja doch eher mal aktuelle Anwendungssoftware haben, und nicht so alte. Auch da würde man wieder ein PPA benutzen, was wieder zu Problemen führt.
        3. Sehr sehr viele (insbesondere kleinere) Programme sind nicht in den offiziellen Repositories vorhanden. Das ist schon das Hauptproblem bei Linux im Allgemeinen: Die Linux-Distri schreibt mir vor, welche Software ich zu benutzen habe. Selber kompilieren ist leider nicht so trivial und man hat nachher einen starken Fremdkörper im System.
        4. Irgendwann ist das System veraltet (es gibt ein neues Release von Ubuntu/Suse usw) und man muss es neu aufsetzen. Windows kann man 4 oder 5 Jahre ohne neue Installation laufen lassen und man hat trotzdem aktuelle Software.

        Punkt 1 und 2 sprechen unbedingt für Arch, könnten aber im Grunde auch von anderen Distris umgesetzt werden. Man müsste dort nur dem Nutzer die Freiheit lassen und außerdem eine Unterscheidung zwischen System- und Anwendersoftware lassen.
        Punkt 3 ist insbesondere durch das AUR gut gelöst: Dort gibt es fast alles, weil die Paketbeschreibungen so einfach zu erstellen sind. Klar funktioniert das AUR nicht immer zuverlässig, aber die Installation von „unwichtigeren“ Programmen ist trotzdem sehr gut gelöst.
        Punkt 4 ist ein guter Vorteil für Rolling Releases, eben da man das System nicht neu installieren muss.

        Außerdem patcht Arch die Pakete (KDE o.ä.) nicht extra, nur damit es „wie Arch“ aussieht. Bei anderen Distris hat man dann ein angepasstes KDE oder Gnome, was mich irgendwie an Android und Samsung- bzw. HTC-Oberflächen erinnert…

        Das einzige was Arch imho fehlt ist eine einsteigerfreundliche Installation und eine simple Konfigurationsoberfläche wie Yast. Aber ich glaube da gibt es ja solche Arch-Abkömmlinge, die das leisten. Müsste ich mir mal anschauen..

        • Ich empfehle dir einen Blick auf Manjaro zu werfen.

        • oder archbang ist minimal mit openbox und kann sich nach der Installation sein System zusammenstellen ist eher was fuer Leute die entweder grafische Oberflaeche besser zurecht kommen oder wie bei mir das mit den Archlinux es problem mit Lan gibt.

          Archbang hat den Vorteil es nutzt die Quellen von Archlinux und alles was mit Archlinux moeglich ist, ist auch mit Archbang moeglich.

          @Ikem Krueger

          Manjaro ist auch eine Moeglichkeit allerdings haben Sie eigene Repos und wie man in Archlinuxforum liesst kann ein Manajro nicht zu einen reinen Archlinux aendern.

    • Sollte auch kein Vergleich mit Ubuntu sein, sondern ein Beispiel dafür was einen als Archler bei größeren Updates erwartet. Grüße, Christoph.

  2. Hai Leute,

    also ich arbeite jetzt auch schon ca. 1 Jahr mit Arch und hatte mit allen Distris, die ich vorher im Einsatz hatte (Fedora, Suse, Ubuntu u.a.) wesentlich mehr Probleme, was die Aktualisierung anbetraf.
    Sicher liegt es auch daran, dass ich immer gerne aktuelle Software einsetze und deswegen z.b. unter Ubuntu mit verschiedenen ppa hantieren musste.

    Aber nach dem Umstieg auf Arch bin ich von der Paketverwaltung begeistert, da sie für mich sehr gut und reibungslos funktioniert.

    Gruß

    Volker

  3. Die Frage die sich mir stellt ist, wie lasse ich die Datei(en) einfach überschreiben, ohne das andere Paket zu deinstallieren?

  4. das ist eine Loesung den Schuldigen zu loeschen oder man baut sich das paket selbst und updates es dann. Ich habe ein paar nicht viele Paket aus aur aber ich installiere Sie mir nicht mit aurqt oder yaourt sonder benutze den PKGBuilder wenn dort schon Fehler auftreten, erzaehlt er mir lieb und brav was fehlt, dann wird das fehlende installiert oder aktualiseirt und dann neu bauen, bisher hat dann alles funktioniert. So kann man auch feststellen ob das paket sauber programmiert wurde.

Hinterlasse eine Antwort

Auf Linux und Ich darf anonym kommentiert werden. Die Felder für Name und E-Mail-Adresse dürfen beim Eintragen eures Kommentars leer bleiben. Ich freue mich aber über jeden Kommentar, zu dem der Autor mit seinem Namen steht.