[solved] Package is already installed

Mein Smart- Upgrade eben hat mal wieder Fehler produziert... Folgende Meldung:
Warum lädt smart Pakete, die schon geladen sind und wirft einen Error aus? Und was genau hat es mit der letzten Meldung auf sich? Wie behebe ich dieses Problem?

Irgendwie läuft smart immer nit so, wie es soll...

Das ist ein Bug, der durch standardmäßiges Abschalten der Option rpm-force neulich eingeführt wurde.

Es kann zwei Gründe geben, weshalb ein bereits installiertes Paket nochmal installiert werden muss:

1) Das Paket wurde in einem Repository neu gebaut, ohne die Release-Nummer zu erhöhen. Jetzt hat es andere Abhängigkeiten als vorher, muss ergo neu installiert werden, um die geänderten Abhängigkeiten aufzulösen, was aber nicht geht, weil rpm ohne --force bzw. --replacepkgs die erneute Installation eines bereits installierten Pakets nicht akzeptiert.

Bug: http://tracker.labix.org/issue208

2) Deine Transaktion versucht, die Architektur eines bereits installierten Pakets zu ändern, z.B. weil irgendwo eine i586-Version irgendeines Pakets aufgetaucht ist, die eine höhere Release-Nummer als die entsprechende x86_64-Version hat. Dadurch wird der Archtekturwechsel aller möglichen abhängigen Pakete angestoßen, dies funktioniert aber nicht.

Bug: http://tracker.labix.org/issue215

Sollte es bei Dir um 2) gehen, dann hast Du Glück, weil es möglicherweise die Zerstörung Deines Systems durch x86_64->i586-Downgrades verhindert haben könnte.

Woran es letztendlich wirklich liegt, kann man nur mithilfe der kompletten Ausgabe von
diagnostizieren. (Die Fehlermeldung am Ende reicht nicht, weil daraus nicht hervorgeht, warum smart das macht, was es macht.)

Okay,
tasten wir uns mal durch. Also, wenn ein Paket neu gebaut wurde, aber die Versionsnummer nicht geändert wurde, dann könnte ich ja einfach die neu zu installierenden Pakete erst entfernen und dann neu installieren, damit wäre das Problem ja durch, oder?

Und zu 2: In einem anderen Thread von mir (http://www.linux-club.de/viewtopic.php?t=68514&highlight=) hattest Du mir empfohlen, das Ersetzen von _x86- Paketen durch neuere i586- Pakete mit der Option zu verhindern. Das hab ich auch gemacht. Insofern denke ich, dass Möglichkeit 2 ausscheidet.

Aber hier die Ausgabe von --explain: http://www.rafb.net/paste/results/2Swzj639.html
Was erkennst Du? Wie gehts weiter?

Nein, es ist genau 2), und rpm-force=False schützt Dich davor, dass smart das System trasht.

Schau die Transaktion doch mal an:

mpd-0.12.0-1.pm.1@i686
Erneuerungen:
mpd-0.12.0rc4-0.pm.1@x86_64 (upgegraded)
Benötigt
libao-0.8.6-19@i586 (installiert)
libid3tag-0.15.1b-32@i586 (installiert)
faad2-2.5-0.pm.2@i586 (installiert)
mad-0.15.1b-1.pm.3@i586 (installiert)
libshout-2.2-15@i586 (installiert)
Konflikte:
mpd-0.12.0rc4-0.pm.1@x86_64 (upgegraded)

Und weiter unten dann:

Installing packages (5):
faad2-2.5-0.pm.2@i586
Benötigt von:
mpd-0.12.0-1.pm.1@i686 (installiert)
libao-0.8.6-19@i586
Benötigt von:
mpd-0.12.0-1.pm.1@i686 (installiert)
libid3tag-0.15.1b-32@i586
Benötigt von:
mpd-0.12.0-1.pm.1@i686 (installiert)
libshout-2.2-15@i586
Benötigt von:
mpd-0.12.0-1.pm.1@i686 (installiert)
mad-0.15.1b-1.pm.3@i586
Benötigt von:
mpd-0.12.0-1.pm.1@i686 (installiert)

=> smart versucht, von allen möglichen Paketen die ix86-Versionen zu installieren.

Und dazu kommt dann noch, dass mpd falsch gepackt ist, im spec-File steht nämlich:

Obsoletes: mpd = 0.12.0rc4

Das geht so nicht, ein Paket kann nicht sich selbst ersetzen. Der Verpacker möchte damit offenbar einen früheren Fehler im Versionsschema wiedergutmachen, aber so geht es garantiert nicht.

Besser wäre:

Version: 0.12.0.0

Das erfüllt denselben Zweck, aus Sicht des rpmvercmp-Algorithmus neuer als 0.12.0rc4 zu sein, aber ohne den unmöglichen Umstand, dass ein Paket versucht, eine laut rpmvercmp neuere Version von sich selbst zu ersetzen.

Insgesamt ist es zum Teil smarts Schuld und zum Teil die des Pakets... Klar dürfte aber sein, dass Du natürlich nicht die ix86-Version von mpd installieren wirst, weil eine x86_64-Version verfügbar ist.

Na prima!
Also das System muss noch etwa 2 Wochen weiterlaufen, dann steht hier eh ein größerer Umbau an. Aber bis dahin darf hier nix kaputtgehn...

Gibt es vielleicht ein Kommando, mit dem ich smart dazu zwinge, die Paketdatenbank zu durchforsten und alle ix86- Pakete durch die jeweils aktuellsten _x86-64er zu ersetzen? Das wäre sicherlich der einfachste Weg.

Alternativ dazu könnte man auch überlegen, die "falschen" Pakete mittels remove zu löschen und die richtigen zu installieren. Allerdings denke ich, dass das einen wahren Rattenschwanz nach sich zieht...

Was schlägst Du vor?

Vorschlagen tu ich gar nichts.

Wer der Sache mal selbst auf den Grund gehen möchte, findet hier eine Python-Version von rpmvercmp:

http://linux.duke.edu/projects/yum/download/misc/rpmvercmp.py

Herunterladen:
Ausführbar machen:
Und vergleichen:
Ergebnis:
Es führt kein Weg dran vorbei: Das RC4-Paket ist neuer als das Final-Paket!

Durch diese Zeile hier
versucht das Final-Paket allerdings zu sagen, es sei neuer als das RC4-Paket.

Also behaupten beide Pakete, neuer als das jeweils andere zu sein => Sorry, kann niemals funktionieren, die Obsoletes-Zeile muss weg und mpd muss mit vernünftigem Versionsschema neu gebaut werden.

Was den Vorschlag angeht, um den Du gebeten hattest: Da das Problem hier nicht die Schuld von smart, sondern die Schuld des mpd-Pakets ist (Provides/Obsoletes/Conflicts-Tricks sind nicht "multiarch-safe"), würde ich erstmal gar nichts besonderes unternehmen, sondern einfach die gewünschte x86_64-Final-Version von mpd manuell auswählen und das Paket dann sperren.

Okay,
ich hab jetzt das mpd-Paket, das ja in der 64er Version installiert war, gelockt und das Upgrade laufen lassen.

Keine Fehlermeldung, hat geklappt.

Danke Dir!

sorry, der fehler ist bei packman, mal schauen, wie wir das lösen können, grml

Jo - das Problem mit "Obsoletes" ist, dass "Obsoletes" sich immer auf alle Architekturen bezieht, d.h. ein Paket foo.i586 mit der Eigenschaft "Obsoletes: bar" ersetzt nicht nur das Paket bar.i586, sondern gleichzeitig auch bar.x86_64.

(Ist übrigens mit "Provides", "Conflicts" und "Requires" genau dasselbe.)

Der Upgrade-Pfad lautet im Moment:

mpd-0.12.0rc4-0.pm.1
mpd-0.12.0-1.pm.1

Problem:
Aber wie wäre es denn mit diesem Vorschlag:

mpd-0.12.0rc4-0.pm.1
mpd-0.12.0-1.pm.1 (schon released...)
mpd-0.12.0.0-0.pm.1

Müsste gehen:
=> Dann wäre auch der "Obsoletes"-Trick mitsamt seinen Nebenwirkungen hinfällig