[solved] Package is already installed

Alles rund um die Installation Eures Linuxsystems, sowie die Updatefunktionen des Systems und das Paketmanagement

Moderator: Moderatoren

Antworten
OmasEnkel
Hacker
Hacker
Beiträge: 572
Registriert: 19. Dez 2005, 14:59
Wohnort: Frankfurt
Kontaktdaten:

[solved] Package is already installed

Beitrag von OmasEnkel » 28. Sep 2006, 22:22

Mein Smart- Upgrade eben hat mal wieder Fehler produziert... Folgende Meldung:

Code: Alles auswählen

Übermittle Transaktion ...
Bereite vor ...                           ######################################################### [  0%]
FEHLER!: package libao-0.8.6-19 is already installed
FEHLER!: package libshout-2.2-15 is already installed
FEHLER!: package faad2-2.5-0.pm.2 is already installed
FEHLER!: package mad-0.15.1b-1.pm.3 is already installed
FEHLER!: package libid3tag-0.15.1b-32 is already installed
FEHLER!: file /usr/bin/faad from install of faad2-2.5-0.pm.2 conflicts with file from package faad2-2.5-0.p  m.2
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...
Zuletzt geändert von OmasEnkel am 29. Sep 2006, 14:57, insgesamt 1-mal geändert.
So long,
OmasEnkel
--------------------

Werbung:
traffic
Guru
Guru
Beiträge: 2750
Registriert: 13. Feb 2005, 05:50

Beitrag von traffic » 29. Sep 2006, 03:07

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

Code: Alles auswählen

smart upgrade --explain
diagnostizieren. (Die Fehlermeldung am Ende reicht nicht, weil daraus nicht hervorgeht, warum smart das macht, was es macht.)
openSUSE Factory - GNOME 2.32.1

OmasEnkel
Hacker
Hacker
Beiträge: 572
Registriert: 19. Dez 2005, 14:59
Wohnort: Frankfurt
Kontaktdaten:

Beitrag von OmasEnkel » 29. Sep 2006, 10:04

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? ... highlight=) hattest Du mir empfohlen, das Ersetzen von _x86- Paketen durch neuere i586- Pakete mit der Option

Code: Alles auswählen

  smart config --set rpm-force=False
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?
So long,
OmasEnkel
--------------------

traffic
Guru
Guru
Beiträge: 2750
Registriert: 13. Feb 2005, 05:50

Beitrag von traffic » 29. Sep 2006, 11:31

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.
openSUSE Factory - GNOME 2.32.1

OmasEnkel
Hacker
Hacker
Beiträge: 572
Registriert: 19. Dez 2005, 14:59
Wohnort: Frankfurt
Kontaktdaten:

Beitrag von OmasEnkel » 29. Sep 2006, 11:53

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?
So long,
OmasEnkel
--------------------

traffic
Guru
Guru
Beiträge: 2750
Registriert: 13. Feb 2005, 05:50

Beitrag von traffic » 29. Sep 2006, 12:05

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/down ... mvercmp.py

Herunterladen:

Code: Alles auswählen

wget http://linux.duke.edu/projects/yum/download/misc/rpmvercmp.py
Ausführbar machen:

Code: Alles auswählen

chmod +x rpmvercmp.py
Und vergleichen:

Code: Alles auswählen

./rpmvercmp.py 0 0.12.0 1.pm.1 0 0.12.0rc4 0.pm.1
Ergebnis:

Code: Alles auswählen

0:0.12.0rc4-0.pm.1 is newer
Es führt kein Weg dran vorbei: Das RC4-Paket ist neuer als das Final-Paket!

Durch diese Zeile hier

Code: Alles auswählen

Obsoletes: mpd = 0.12.0rc4
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.
openSUSE Factory - GNOME 2.32.1

OmasEnkel
Hacker
Hacker
Beiträge: 572
Registriert: 19. Dez 2005, 14:59
Wohnort: Frankfurt
Kontaktdaten:

Beitrag von OmasEnkel » 29. Sep 2006, 14:56

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!
So long,
OmasEnkel
--------------------

drcux
Hacker
Hacker
Beiträge: 370
Registriert: 9. Aug 2005, 12:14

Beitrag von drcux » 29. Sep 2006, 23:02

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

traffic
Guru
Guru
Beiträge: 2750
Registriert: 13. Feb 2005, 05:50

Beitrag von traffic » 30. Sep 2006, 07:23

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:

Code: Alles auswählen

% ./rpmvercmp.py 0 0.12.0rc4 0.pm.1 0 0.12.0 1.pm.1
0:0.12.0rc4-0.pm.1 is newer
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:

Code: Alles auswählen

% ./rpmvercmp.py 0 0.12.0rc4 0.pm.1 0 0.12.0.0 0.pm.1
0:0.12.0.0-0.pm.1 is newer
% ./rpmvercmp.py 0 0.12.0 1.pm.1 0 0.12.0.0 0.pm.1
0:0.12.0.0-0.pm.1 is newer
=> Dann wäre auch der "Obsoletes"-Trick mitsamt seinen Nebenwirkungen hinfällig ;)
openSUSE Factory - GNOME 2.32.1

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast