Updater Applet, zypper up und Yast=unterschiedliche Updates

[Schlafmuetze]

Mag sein, aber mir ist bei Yast teilweise aufgefallen das es Abhängigkeiten installiert, die wenn ich sie aus Spaß mal deinstalliere keine Warnmeldung ausgeben aufgrund von Abhängigkeitsproblemen.

 

[whois]

Kannst du mal ein Beispiel nennen um das nach zu vollziehen.
Das ist etwas zu allgemein um mehr dazu sagen zu können.

 

[Schlafmuetze]

Nein, mir fällt keins ein. Da ich hauptsächlich nur noch mit Zypper arbeite und nur bei Problemen Yast benutze.
Allerdings hatte ich ja gestern Updates gezogen, da Stand bei Zypper als Datenmenge was von ca. 150MB und bei Yast über 500MB.

 

[whois]

350 MB Unterschied. :schockiert:
Das kann ich mir fast kaum vorstellen.
Bitte Achte mal demnächst darauf was das alles ist, weil das interessiert mich ehrlich.
Mal sehen ob ich das am Wochenende nachspielen kann.

 

[Schlafmuetze]

Mach ich. Aber ich habe noch eine letzte Frage, die rührt vor allem daher das ich keine Ahnung habe wie das mit den Respositories funktioniert.
Und zwar, ich hatte gestern 'ne Programmbibliothek updaten wollen (also so 'ne libxxxx), sie wurde sowohl unter Zypper als auch unter Yast als updatefähig angezeigt. Das entsprechende Paket konnte aber in der entsprechenden Respository nicht gefunden werden.
Woran kann das liegen? Wird für die Respository so 'ne Art Index erstellt in der drin steht welche Pakete enthalten sind, welche Version sie haben etc. und das wird dann mit meinen installierten Paketen verglichen? Und war es in dem Fall so das der Index aktualisiert war das Paket aber noch nicht auf die Respository gespielt?

 

[whois]

Ja das hast du richtig erkannt.
Ein Repository ist im Prinzip nichts anderes als eine Datenbank in der vorhande Pakete auf deinem PC mit aktuellen Paketen der DB abgeglichen werden.
Dieses indexieren kann manchmal Fehler versursachen wenn Pakete zwar im Index vorhanden sind aber im "Depot" noch nicht.

 

[Tooltime]

@Tooltime
CODE: ALLES AUSWÄHLEN
S | Name | Typ | Version | Arch | Repository
--+------------+-------+-------------+------+---------------------
v | kde4-kfind | Paket | 4.1.3-3.8.9 | i586 | openSUSE-11.1-Update
v | kde4-kfind | Paket | 4.2.4-1.4 | i586 | 42
v | kde4-kfind | Paket | 4.1.3-3.7 | i586 | openSUSE-11.1-Oss
i | kde4-kfind | Paket | 4.2.4-1.3 | i586 | (Systempakete)


Als ich das gelesen hatte dachte ich erst das es eventuell an der 42-Respository liegt und Yast darauf nicht zugreift. Allerdings sind die Pakete die von Yast ebenfalls als Version 4.2.-x angegeben sind auch von dieser Respository.

Ich wette wenn du in YaST die Softwareverwaltung startest, nach kde4-kfind suchst und dort mal auf den Tab "Versionen" klickst wird genau das Gleiche angezeigt.

Nachtrag:
Ich hab jetzt mal die "openSUSE-11.1-Update"-Respository entfernt und nun funktioniert es.

Eine schlechte Idee, aber war klar das die zum Erfolg führt.

Das Ganze ist ein Problem der Prioritäten der einzelnen Repositories. Aber Zuerst sollte die Bedeutung von ein paar Begriffen geklärt werden.

• 1. Du hast keine Probleme mit updates sondern mit upgrades.
  Das einzige Repository mit Updates das ich kenne, ist das Update-Repo von openSUSE. Ein Update behebt Fehler in einem Software-Paket.
  Ein Upgrade ersetzt ein Softwarepaket durch eins mit einer höheren Versionsnummer. Die neue Version kann auf Grund neuer Feature mehr Fehler enthalten als die Alte. Das trifft insbesonbere auf Pakete aus factory-Zweigen zu, da der letzte Entwicklungsstand oft ungeteste Programmkomponenten enthält.
  Und als letztes gibt es noch das Distribution Upgrade, hierbei kann ein Paket auch automatisch die Quelle wechseln. Praktisch eine Art "mach was du willst zypper".
  
  2. Normaler Weise wird ein Softwarepaket nicht automatisch durch eines aus einem anderen Repository ersetzt (update o. upgrade). Das Resultat sind oft angezeigte Aktualisierungen (höhere Versionsnummer) im Update-Applet die nicht eingespielt werden können.

Dein Problem beruht auf der Priorität der Repository, da das Update-Repo die höchste Prio hat, werden die Paketversionen von dort bevorzugt. Vor allem YaST verhält sich so und bietet daher gerne KDE-4.1-Pakete zum installieren an. Daher ist es wichtig mal im Gedanken durch zu spielen welche Quelle durch welche ersetzt werden darf.

• Update-Repo --> ersetzt Standardpakete.
  Packman --> Pakete mit größeren Funktionsumfang, sollten nicht durch Updates oder andere ersetzt werden.
  KDE4.2 --> Sollten keine Packmann-Pakete ersetzen, stehen aber über Updates wegen anderer KDE-Version.
  Qt-KDE4.2 --> Qt speziell für KDE 4.2 sollten von niemanden anderen ersetzt werden.

Ergibt für mich:

• Standart-Repos --> Prio 99
  Update-Repo --> Prio 50
  Packman --> Prio 30
  KDE-4.2 --> Prio 30
  QT-KDE4.2 --> Prio 30

Bei gleichen Prioritäten muss man sich manuell einmal entscheiden aus welchen Repo das Paket genommen werden soll. Bei updates oder upgrades wird die Quelle ja bei behalten und damit läßt sich die installierte Software dann auch problemlos mit dem Updater auf den aktuellen Stand halten.

 

[Schlafmuetze]

Vielleicht habe ich nicht alles verstanden, aber wieso war das eine schlechte Idee?
Ich meine, wenn es empfohlen wird anstellen von KDE4.1.3 KDE4.2 einzusetzen, dann sollte es meiner Meinung nach klar sein das Suse das automatisch so in die Respositories setzt das dieses Update automatisch funktioniert und nicht das man erst ewig rumfummeln muss.
Zudem bleibt ja dann trotzdem noch die Frage wieso teilweise die Version 4.2.4 als aktuelle angegeben war und bei anderen Paketen Version 4.1.3. Denn die Pakete kamen schließlich alle von der gleichen Respository. Und wenn es 2 gleiche Pakete auf unterschiedlichen Respositories gibt, dann würde das Paket doch dann sicher von der Respository mit der höheren Priorität genommen werden. Dem war aber anscheinend nicht der Fall.

 

[Tooltime]

Vielleicht habe ich nicht alles verstanden, aber wieso war das eine schlechte Idee?

Weil jetzt alle Pakete aus den Standard-Repo's (OSS und NON-OSS) nicht mehr aktualisiert werden.

dann sollte es meiner Meinung nach klar sein das Suse das automatisch so in die Respositories setzt das dieses Update automatisch funktioniert und nicht das man erst ewig rumfummeln muss.

1. Ist kein Update sondern ein Upgrade, habe versucht den Unterschied zu erklären.
2. Alles was nicht aus den Repo's OSS, NON-OSS und Update kommt wird als Fremdprodukt behandelt, Installation daher auf eigenes Risiko, die Aktualisierung ist immer ein Upgrade.

Zudem bleibt ja dann trotzdem noch die Frage wieso teilweise die Version 4.2.4 als aktuelle angegeben war und bei anderen Paketen Version 4.1.3. Denn die Pakete kamen schließlich alle von der gleichen Respository.

Nö, waren unterschiedliche Repo's.

Und wenn es 2 gleiche Pakete auf unterschiedlichen Respositories gibt, dann würde das Paket doch dann sicher von der Respository mit der höheren Priorität genommen werden. Dem war aber anscheinend nicht der Fall.

Genau das ist passiert!

Beispiel kde4-kfind:

• 
  Zur Erinnerung die Repo-Infos
  

  v | kde4-kfind | Paket | 4.1.3-3.8.9 | i586 | openSUSE-11.1-Update
  v | kde4-kfind | Paket | 4.2.4-1.4 | i586 | 42
  v | kde4-kfind | Paket | 4.1.3-3.7 | i586 | openSUSE-11.1-Oss
  i | kde4-kfind | Paket | 4.2.4-1.3 | i586 | (Systempakete)

  Da per default das Update-Repo die höchste Prio hat, ist die bevorzugte Version 4.1.3-3.8.9
  Löscht man das Update-Repo, ohne manellen Eingriff haben allen anderen Repo's die gleiche Prio, gewinnt die höchste Versionsnummer 4.2.4-1.4. Das gleiche betrifft KDE4-Pakete die nicht im Update-Repo vertreten sind.

Fazit:

• 
  Gab es im Update-Repo ein entsprechendes KDE4-Paket --> Version 4.1.x
  Gab es im Update-Repo kein entsprechendes KDE4-Paket --> Version 4.2.x