Hallo openSUSE Freunde.
Die Tage habe ich ein frisches openSUSE 12.1 x86_64 von DVD installiert und nutze als Desktop KDE 4.x.
Nutzt jemand von euch die Tumbleweed Repos?
Hier im Forum habe ich gelesen, dass man bei Tumbleweed alle Repos auf die gleiche Priorität setzten sollte und bei aktivierten Tumbleweed-Repos alle anderen Repos deaktivieren sollte. Ich sehe da aber evtl. Probleme. Gerne würde ich mit euch mal kurz darüber diskutieren und ein Beispiel geben. Vielleicht schreibt ihr mal eure Erfahrungen, wie ihr es macht.
Gemäß der Anleitung auf http://en.opensuse.org/Tumbleweed habe ich die 4 entsprechenden openSUSE Tumbleweed Repos (Current-OSS, Current-nonOSS, Current-updates und Tumbleweed:standard) hinzugefügt und die Standard-Repos (also OSS, non-OSS und updates) deaktiviert. Einige weitere Repos habe ich noch hinzugefügt: Z.B. die Packman-Tumbleweed Variante, Mozilla, das KDE-Release47 Repo, KDE-Extras-Tumbleweed sowie ein paar andere.
Gehen wir mal davon aus, dass alle Repos die Standard-Priorität 99 haben. Nun führe ich ein zypper dup aus und mal sehen was passiert: Unter Berücksichtigung aller Abhängigkeiten wird aus allen Repos jeweils das Paket mit der höchsten Versionsnummer genommen. Im KDE:Release47 Repo befindet sich KDE 4.7.3 (aktuelle Bugfix-Version). Im Tumbleweed Repo Current-OSS befindet sich ebenfalls ein KDE, aber die ältere Version 4.7.2. Im Gegensatz dazu sind im KDE Repo hingegen einige Pakete, die dafür im Tumbleweed Repo Current-OSS aktueller sind.
Wo ist das Problem?
Ein zypper dup sucht nun die aktuellste Paketversion, nimmt also z.B. kdelibs4 aus dem KDE Repo, Strigi hingegen, was ebenfalls Bestandteil von KDE ist, dafür aber aus dem Tumbleweed Repo. Genauso wäre es z.B. bei Bluedevil, der Bluetooth-Komponente von KDE. Dort ist die aktuellere Version in Tumbleweed und die ältere im KDE-Repo.
Ein zypper dup würde mir sozusagen ein gemischtes System liefern: Eine KDE 4.7.3 Installation, jedoch teilweise mit Komponententen aus dem Tumbleweed Repo, z.B. aktuelleres Bluetooth-Subsystem. Hätte ich nur Tumbleweed, hätte ich dafür eine ältere KDE Version mit aktuellem Bluetooth-Subsystem. Hmm. Haben alle Repos also die gleiche Prio, hätte ich aus Sicht der Paketversionsnummer das aktuellste System, aber darür aus verschiedenen Repos durcheinander gewürfelt.
Wie sollte man das denn nun am besten konfigurieren? Ich habe dem KDE-Reps eine höhere Priorität (z.B. 30) zugewiesen und die Tumbleweed-Repos auf eine geringere Prio gesetzt (z.B. 99).
Ein zypper dup holt nun KDE 4.7.3 aus dem KDE-Repo, da dieses Repo bei einem dup bevorzugt wird. Teile von KDE, die in Tumbleweed aktueller sind, z.B. Bluedevil, Strigi, etc., bekomme ich so allerdings NICHT. Der Vorteil ist aber, dass ich mit den KDE-Komponenten innerhalbt eines Repos bleibe, nämlich wegen der höheren Prio des KDE-Repos.
Liege ich damit richtig, dass dies der bessere Weg ist zugunsten von höherer Stabilität, als wenn alles aus unterschiedlichen Repos zusammengewürfelt wird? So richtig verstehe ich den Sinn von Tumbleweed dann nicht, wenn dort Teile älter sind, andere Teile wiederum wesentlich aktueller als im KDE-Repo sind. Wie nutzt ihr die Tumbleweed Repos denn und wie setzt ihr die Prioritäten bzw. wie aktualisiert ihr euer System?
Es gibt ja noch die Möglichkeit, die Repos per Conf-Datei auf sticky zu setzen. Im SDB wird dies als "vendor stickyness concept" bzw. siehe auch "packages ping-ponging": http://en.opensuse.org/SDB:Vendor_change_update
Verstehe ich das richtig, dass man bei vendor stickyness (in Yast heisst das dann "Wechsel von Systempaketen") auf eine Regelung über Prioritäten verzichten kann? Wenn ich richtig liege, müsste man dann in /etc/zypp eine entsprechende Config Datei manuell anlegen...
Gr. Kai
Die Tage habe ich ein frisches openSUSE 12.1 x86_64 von DVD installiert und nutze als Desktop KDE 4.x.
Nutzt jemand von euch die Tumbleweed Repos?
Hier im Forum habe ich gelesen, dass man bei Tumbleweed alle Repos auf die gleiche Priorität setzten sollte und bei aktivierten Tumbleweed-Repos alle anderen Repos deaktivieren sollte. Ich sehe da aber evtl. Probleme. Gerne würde ich mit euch mal kurz darüber diskutieren und ein Beispiel geben. Vielleicht schreibt ihr mal eure Erfahrungen, wie ihr es macht.
Gemäß der Anleitung auf http://en.opensuse.org/Tumbleweed habe ich die 4 entsprechenden openSUSE Tumbleweed Repos (Current-OSS, Current-nonOSS, Current-updates und Tumbleweed:standard) hinzugefügt und die Standard-Repos (also OSS, non-OSS und updates) deaktiviert. Einige weitere Repos habe ich noch hinzugefügt: Z.B. die Packman-Tumbleweed Variante, Mozilla, das KDE-Release47 Repo, KDE-Extras-Tumbleweed sowie ein paar andere.
Gehen wir mal davon aus, dass alle Repos die Standard-Priorität 99 haben. Nun führe ich ein zypper dup aus und mal sehen was passiert: Unter Berücksichtigung aller Abhängigkeiten wird aus allen Repos jeweils das Paket mit der höchsten Versionsnummer genommen. Im KDE:Release47 Repo befindet sich KDE 4.7.3 (aktuelle Bugfix-Version). Im Tumbleweed Repo Current-OSS befindet sich ebenfalls ein KDE, aber die ältere Version 4.7.2. Im Gegensatz dazu sind im KDE Repo hingegen einige Pakete, die dafür im Tumbleweed Repo Current-OSS aktueller sind.
Code:
Beispiel:
Paket Strigi (befindet sich sowohl im Tumbleweed Repo als auch im KDE-Repo):
KDE Repo: Version 0.7.5-2.1 (älter)
Current-OSS Repo: 0.7.5-5.1 (aktueller)
Paket kdelibs4 (befindet sich sowohl im Tumbleweed Repo als auch im KDE-Repo):
KDE Repo: Version 4.7.3-10.2 (aktueller)
Current-OSS Repo: 4.7.2-5.2.2 (älter)
Ein zypper dup sucht nun die aktuellste Paketversion, nimmt also z.B. kdelibs4 aus dem KDE Repo, Strigi hingegen, was ebenfalls Bestandteil von KDE ist, dafür aber aus dem Tumbleweed Repo. Genauso wäre es z.B. bei Bluedevil, der Bluetooth-Komponente von KDE. Dort ist die aktuellere Version in Tumbleweed und die ältere im KDE-Repo.
Ein zypper dup würde mir sozusagen ein gemischtes System liefern: Eine KDE 4.7.3 Installation, jedoch teilweise mit Komponententen aus dem Tumbleweed Repo, z.B. aktuelleres Bluetooth-Subsystem. Hätte ich nur Tumbleweed, hätte ich dafür eine ältere KDE Version mit aktuellem Bluetooth-Subsystem. Hmm. Haben alle Repos also die gleiche Prio, hätte ich aus Sicht der Paketversionsnummer das aktuellste System, aber darür aus verschiedenen Repos durcheinander gewürfelt.
Wie sollte man das denn nun am besten konfigurieren? Ich habe dem KDE-Reps eine höhere Priorität (z.B. 30) zugewiesen und die Tumbleweed-Repos auf eine geringere Prio gesetzt (z.B. 99).
Ein zypper dup holt nun KDE 4.7.3 aus dem KDE-Repo, da dieses Repo bei einem dup bevorzugt wird. Teile von KDE, die in Tumbleweed aktueller sind, z.B. Bluedevil, Strigi, etc., bekomme ich so allerdings NICHT. Der Vorteil ist aber, dass ich mit den KDE-Komponenten innerhalbt eines Repos bleibe, nämlich wegen der höheren Prio des KDE-Repos.
Liege ich damit richtig, dass dies der bessere Weg ist zugunsten von höherer Stabilität, als wenn alles aus unterschiedlichen Repos zusammengewürfelt wird? So richtig verstehe ich den Sinn von Tumbleweed dann nicht, wenn dort Teile älter sind, andere Teile wiederum wesentlich aktueller als im KDE-Repo sind. Wie nutzt ihr die Tumbleweed Repos denn und wie setzt ihr die Prioritäten bzw. wie aktualisiert ihr euer System?
Es gibt ja noch die Möglichkeit, die Repos per Conf-Datei auf sticky zu setzen. Im SDB wird dies als "vendor stickyness concept" bzw. siehe auch "packages ping-ponging": http://en.opensuse.org/SDB:Vendor_change_update
Verstehe ich das richtig, dass man bei vendor stickyness (in Yast heisst das dann "Wechsel von Systempaketen") auf eine Regelung über Prioritäten verzichten kann? Wenn ich richtig liege, müsste man dann in /etc/zypp eine entsprechende Config Datei manuell anlegen...
Gr. Kai