Zypper Prioritäten bei Tumbleweed+KDE und vendor stickyness

m00nraker · 25 Nov. 2011

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.

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)

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

drcux · 27 Nov. 2011

/etc/zypper/zypp.conf
# solver.allowVendorChange = false

m00nraker · 27 Nov. 2011

Was möchtest Du mit dieser "ausführlichen" Antwort aussagen? (Trotzdem danke

)

Auszug aus zypp.conf:

EXPERTS ONLY: Per default the solver will not replace packages of
## different vendors, unless you explicitly ask to do so. Setting this
## option to TRUE will disable this vendor check (unless the application
## explicitly re-enables it). Packages will then be considered based on
## repository priority and version only. This may easily damage your system.
##
## CHANGING THE DEFAULT IS NOT RECOMMENDED.
##
## Valid values: boolean
## Default value: false
##
# solver.allowVendorChange = false

VendorChange ist also schon per Default auf false gesetzt, dass muss mal nicht explizit tun.

Aber irgendwas stimmt da nicht so richtig oder ich verstehe es vielleicht nicht richtig. Ich habe noch mal ein wenig rumexperimentiert:

Setze ich per Yast alle Repos auf die gleiche Prio (dies ist der "'Normalfall"), erfolgt bei einem zypper dup trotz VendorChange=false ein Vendor Change bezüglich der höchsten Paketversionsnummer. Das System wird also aus gemischten Repos geupdatet.

Setze ich dagegen Prioritäten, z.B. die KDE-Repos auf höhere Prio (30) und die Tumbleweed-Repos auf geringere Prio (99),
zieht ein zypper dup NICHT aktuellere Pakete aus dem Tumbleweed-Repo, sondern nur dann, wenn sie im KDE-Repo aktueller sind. Zypper springt also nicht dauernd hin und her.

Beispiel: Amarok hat im Tumbleweed eine höhere Versionsnummer. Im KDE47 Repo aber eine kleinere Versionsummer. Hat das KDE-Repo aber eine höhere Prio, zieht Zypper bei einem zypper dup eben nicht das aktuellere Paket aus dem Tumbleweed Repo. Somit vollzieht Zypper KEINEN VendorChange aufgrund der gesetzten Prioritäten. Haben die Repos aber gleiche Prio, z.B. alle auf 99, dann würde Zypper Amarok aus dem Tumbleweed updaten (weils dort die höchste Versionsnummer hat), die anderen Teile von KDE aber wiederum aus dem KDE-Repo holen (weil einige Teile dort die höchste Versionsnummer haben). Somit hätte man ein gemischtes System (dies wäre nur ein kleines Beispiel). Man denke nun an wichtigere Dateien des Systems. Für mich steht das aber im Widerspruch zu dem, wie sich Zypper gemäßt der Einstellungen in zypp.conf bezüglich VendorChange verhalten sollte (siehe oben).

Fazit:
Läßt man die zypp.conf bezüglich Vendor-Change unangetastet, SOLLTE man also bei mehreren Repos Prioritäten richtig setzen, damit das System nicht durcheinandergewürfelt wird. Die Aussage: Bei Nutzung von Tumbleweed sollten alle Repos die gleiche Priorität haben, wäre demnach absolut nicht empfehlenswert. Oder verstehe ich da was falsch?

gropiuskalle · 27 Nov. 2011

VendorChange ist also schon per Default auf false gesetzt, dass muss mal nicht explizit tun.

Nö, ist ja auskommentiert.

m00nraker · 27 Nov. 2011

Wo bitte ist VendorChange auf true gesetzt?

Dann lies mal richtig, was in zypp.conf als Kommentar geschrieben steht:

Default value: false

Und nu?

Appleonkel · 27 Nov. 2011

m00nraker schrieb:
Gemäß der Anleitung auf http://en.opensuse.org/Tumbleweed

http://en.opensuse.org/Tumbleweed schrieb:
The only supported method of repo use for Tumbleweed is to have only the main repos (Oss, Non-oss, and Update) and the Tumbleweed repo active.

Ich versteh dein Problem nicht, wenn du ein aktuelles KDE neben Tumbleweed haben willst, solltest du schon wissen was du machst

Wenn du meinst, dass es funktioniert das KDE-Repo mehr Priorität zu geben, dann ist das Ok. Niemand kann und wird dir garantieren, dass das stabil läuft. Vielleicht läuft es stabil aber mit 90% Wahrscheinlichkeit wird dir das irgendwann um die Ohren fliegen!

m00nraker · 27 Nov. 2011

Und ich verstehe Deinen Kommentar nicht :???:

http://en.opensuse.org/Tumbleweed hat geschrieben:The only supported method of repo use for Tumbleweed is to have only the main repos (Oss, Non-oss, and Update) and the Tumbleweed repo active.

Dort steht nur, dass es nicht supportet wird, was nun mal eine ganz andere Baustelle ist. Wenn Du danach gehst, dürftest Du viele Dinge an Deiner Suse nicht ändern, weil es ja nicht supportet wird. Aber darum geht es doch nicht.

Tumbleweed ermöglicht eine Art Rolling Release mit Gewicht auf Stabilität. Möchte man dies, bleibt man eben nur bei diesen 4 Tumbleweed Repos. Was spricht aber dagegen, bei aktiviertem Tumbleweed trotzdem ein akuelles KDE Bugfix-Release aus einem KDE Repo installiert zu haben? In Tumbleweed sind eben nicht nur KDE Pakete enthalten, sondern auch eine ganze Menge anderer Pakete. Leider ist KDE dort aber nicht ganz aktuell, deswegen z.B. ein zusätzliches KDE Repo. Mir geht es darum, dass Pakete nicht aus verschiedenen Repos durcheinandergewürfelt werden, sobald man mehrere Repos aktiviert. Deswegen versuche ich die Arbeitsweise von Zypper zu verstehen, verstehe es aber "anscheinend?" nicht richtig. Denn bei zypper dup beobachte ich schon lange Zeit, dass immer wieder Vendor-Wechsel stattfinden.

Läßt sich dies also nur durch setzen der richtigen Prioritäten vermeiden? Warum wird in zypp.conf dann geschrieben, dass defaultmäßig kein Vendor-Wechsel stattfindet? Für die Problematik habe ich doch mehrere Beispiele gegeben.

Von mir aus lass Tumbleweed ganz weg und füge ein paar andere Repos hinzu (z.B, wine, gnome, kde, mozilla...). Ist dann die gleiche Situation... Auch so kommt es zum "Paket-Hopping".

Appleonkel · 27 Nov. 2011

Wenn du keine Vendorwechsel möchtest mach kein zypper dup sondern zypper up.
Um nur einen Vendorwechsel zu dein KDE-Repo zu haben

Code:

zypper dup --from KDE-Repo

Ansonsten bleibt dir noch die Möglichkeit Pakete zu pinnen und per Hand bestimmte Version aus bestimmten Repos zu installieren oder aber auch die schon von dir entdeckte Möglichkeit des "vendor stickyness concept".

gropiuskalle · 27 Nov. 2011

Ja, bei einem 'dup' zählen vendor stickyness ohnehin nicht, die entsprechende Option bezieht sich auf 'up'. Und das mit dem "supported" heißt eher, dass die beschriebene Methode einfach Sinn ergibt, während das Mischen von Tumbleweed und z.B. bleeding-edge KDE-Repos nicht sinnvoll ist. Zumindest muss man die Paketauswahl dann recht umständlich verwalten, einen Mehrwert erkenne ich aber nicht.

m00nraker · 28 Nov. 2011

Also vielen Dank, AppleOnkel und *Kalle

Habs gerafft. Die entscheidene Info für mich war nun doch, dass sich Vendor-Change nur auf dup bezieht und nicht auf up.Nun kann ich nachvollziehen, warum Zypper das macht.

Ich habe mal getestet: Wenn ich in zypp.conf AllowVendorChange auf true setze, verhält sich ein zypper up genau so wie zypper dup. Beim Update wird dann auch ein Vendor-Change vollzogen. Aber dies sollte man lassen. Lasse also zypp.conf unverändert.

Nun noch eine Bitte an euch:

Ich beschreibe mal kurz meine Repos:

Vorhandene Repos allesamt deaktiviert. Dann die 4 Tumbleweed-Repos hinzugefügt, jeweils mit Prio 99. Dies ermöglicht somit ein Rolling-Release. Nun führe ich ein zypper dup durch. Das System wird auf Tumbleweed geupdatet, mit Vendor-Change. Da in Tumbleweed aber "nur" KDE 4.7.2 enthalten ist und ich aber das aktuelle Bugfix-Release haben möchte, habe ich sowohl das KDE-Repo als auch das KDE-Extra-Tumbleweed-Repo jeweils mit Prio 99 hinzugefügt. Würde ich nun ein zypper dup machen, würde Zypper das jeweils aktuellste Paket aus jedem Repo nehmen und das System durcheinander würfeln. Ein zypper update würde in diesem Fall ja nicht helfen, da es zu keinem Vendor-Change kommen würde und es bliebe weiterhin KDE 4.7.2 aus dem Tumbleweed-Repo installiert. Aus diesem Grund würde ich nun die Prioritäten der beiden KDE-Repos auf eine höhere Prio setzen, z.B. auf 50. Nun führe ich ein zypper dup durch, es kommt zu einem Vendor-Change und Zypper würde die KDE-Pakete diesmal bevorzugen. Ich hätte also Tumbleweed mit einem aktuellen KDE 4.7.3 und das System wäre nicht durchinander gewürfelt. Künftige Aktualisierungen würde ich dann nur durch zypper update durchführen.

Code:

Prio    Repo
30       KDE:Release47
30       KDE:Extra:openSUSE-Tumbleweed
99       Tumbleweed-Repos: Current-Oss, Current-Non-Oss, Update, Tumbleweed:standard

Letzte Fragen dazu:

1) Wäre dies von der Vorgehensweise so korrekt, wenn ich Tumbleweed+aktuelles KDE haben möchte?

2) Das System müsste dann doch genauso stabil sein, als wenn KDE direkt aus dem Tumbleweed kommt, oder?

3) Wenn man das KDE-Repo und das Current-OSS Repo vergleicht, fällt auf, dass die KDE-Basis Pakete im KDE-Repos aktueller als im Tumbleweed sind. Könnt ihr mir sagen, warum viele KDE Pakete in Tumbleweed top aktuell sind, die KDE-Basis-Pakete allerdings hinterherhinken (Version 4.7.2)??

4) Wann genau benutzt ihr "zypper dup" anstelle von "zypper update"?

5) Setzt ihr eure Repos auf unterschiedliche Prioritäten, wenn ja wie und warum?

Vielen Dank an euch...

gropiuskalle · 28 Nov. 2011

1) Wäre dies von der Vorgehensweise so korrekt, wenn ich Tumbleweed+aktuelles KDE haben möchte?

Müsste hinhauen, ich würde aber sicherheitshalber das von Appleonkel vorgeschlagene

Code:

zypper dup --from KDE-Repo

anwenden.

2) Das System müsste dann doch genauso stabil sein, als wenn KDE direkt aus dem Tumbleweed kommt, oder?

Uff, gute Frage, aber soweit ich weiß, werden Tumbleweed und die KDE-Repos von separaten Teams betreut, das muss sich im einzelnen nicht decken. Du hast ja schon feststellen können, dass die Versionen nicht deckungsgleich sind.

3) Wenn man das KDE-Repo und das Current-OSS Repo vergleicht, fällt auf, dass die KDE-Basis Pakete im KDE-Repos aktueller als im Tumbleweed sind. Könnt ihr mir sagen, warum viele KDE Pakete in Tumbleweed top aktuell sind, die KDE-Basis-Pakete allerdings hinterherhinken (Version 4.7.2)??

Beide Repos suchen den Kompromiss zwischen Stabilität und Aktualität, liegen also irgendwo zwischen 'oss' und 'Factory' - das kann bisweilen eine weite Spanne sein.

4) Wann genau benutzt ihr "zypper dup" anstelle von "zypper update"?

Ich benutze das grundsätzlich, allerdings sind meine Repos bzw. Locks dementsprechend eingerichtet. Eigentlich ist diese Methode v.a. dafür bestimmt, ein openSUSE auf eine komplett neue Version zu hieven (siehe auch den entsprechenden Hinweis von zypper bei einem 'dup').

5) Setzt ihr eure Repos auf unterschiedliche Prioritäten, wenn ja wie und warum?

Das ist auf jeden Fall zu empfehlen, denn nicht wenige Pakete werden von mehreren Quellen angeboten. Wie man Prios setzt, ist allerdings sehr stark davon abhängig, welche Repositories man verwendet und was man will.

Appleonkel · 28 Nov. 2011

Ganz einfach immer zypper dup und mein Repoliste sieht so aus

Code:

# | Alias                           | Name                                           | Aktiviert | Aktualisieren | Priorität | URI                                                                              
--+---------------------------------+------------------------------------------------+-----------+---------------+-----------+----------------------------------------------------------------------------------
1 | Hauptaktualisierungs-Repository | Hauptaktualisierungs-Repository                | Ja        | Ja            |   99      | http://download.opensuse.org/update/12.1/
2 | Tumbleweed                      | Tumbleweed                                     | Ja        | Ja            |   99      | http://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/
3 | devel_tools                     | Generic Development Tools (openSUSE_12.1)      | Ja        | Ja            |   99      | http://download.opensuse.org/repositories/devel:/tools/openSUSE_12.1/
4 | download.opensuse.org-oss       | openSUSE-12.1-Oss                              | Ja        | Nein          |   99      | http://download.opensuse.org/distribution/12.1/repo/oss
5 | download.opensuse.org-python    | openSUSE BuildService - devel:languages:python | Ja        | Ja            |   70      | http://download.opensuse.org/repositories/devel:/languages:/python/openSUSE_12.1/
6 | openSUSE-11.4-Non-Oss           | openSUSE-12.1-Non-Oss                          | Ja        | Nein          |   99      | http://download.opensuse.org/distribution/12.1/repo/non-oss/
7 | openSUSE:Tools                  | openSUSE:Tools                                 | Ja        | Ja            |   99      | http://download.opensuse.org/repositories/openSUSE:/Tools/openSUSE_12.1/
8 | packman-essentials              | packman-essentials                             | Ja        | Ja            |   99      | http://packman.inode.at/suse/openSUSE_Tumbleweed/Essentials

Und falls bei python mal was fehlschlagen sollte (was bei python relativ unwahrscheinlich ist) dann weiss ich mir zu helfen

m00nraker · 29 Nov. 2011

@ *kalle, danke für die Antworten.

4) Wann genau benutzt ihr "zypper dup" anstelle von "zypper update"?

Ich benutze das grundsätzlich, allerdings sind meine Repos bzw. Locks dementsprechend eingerichtet. Eigentlich ist diese Methode v.a. dafür bestimmt, ein openSUSE auf eine komplett neue Version zu hieven (siehe auch den entsprechenden Hinweis von zypper bei einem 'dup').

Ok, wenn Du immer zypper dup anwendest, musst Du also zwangsweise eine gute Prioritätenhierarchie bei Deinen Repos einführen. Dann kannst Du getrost immer ein zypper dup ausführen. Allerdings wäre dies in diesem Fall gleichbedeutend, wenn Du "nur" zypper update ausführen würdest, wegen den Prioritäten.

Also ich werde es nun künftig so halten, für meinen Anwendungsfall geeignete Prios setzen, einmal zypper dup um auf die neuen Repos zu wechseln und für den laufenden Betrieb zwischendurch zypper update. Zypper bleibt dann künftig innerhalb der jeweiligen Repos, bedingt durch die Prios.

@AppleOnkel:

Auch Dir danke für Deine Antworten. Du schreibst, dass Du immer zypper dup benutzt. Wenn ich mir allerdings Deine Repoliste ansehe, fällt mir was auf: Du hast alle Repos auf Prio 99, bis auf das Python Repo, was eine höhere Prio aufweist. Zudem benutzt Du aber nur eines der 4 Tumbleweed-Repos, hast aber gleichzeitig die normalen OSS, NON-OSS und Update Repos drin. Das sollte ja gerade nicht so sein (entweder nur die normalen Repos oder die Tumbleweed-Version). In Deinem hinzugefügten Tumbleweed steht zwar aktuell nur was mit git drin, aber das kann sich ändern. Da alle anderen Repos die gleiche Prio haben (99), kann ein zypper dup zu einem ständigen Hersteller-Wechsel führen. Dein System könnte dann vielleicht instabil werden.

Zum Vergleich mal meine Repo-Liste (Kritik erwünscht). Wichtig sind die Prioritäten. Ein dup holt das von mir gewünschte KDE aus dem KDE Repo, hat also Vorrang vor Tumbleweed. Packman hat die höchste Prio, da ich mir dann z.B. keine Sorgen um Codecs & Co. machen muss. So wird k3b z.B. immer von Packman bezogen und hat gleich das mp3-Plugin mit drin. Im laufenden Betrieb reicht dann ein update aus und alles ist aktuell. Sollte sich für mich rausstellen, dass Tumbleweed vielleicht nur ein oder zwei Monate dem KDE Repo hinterherhinkt, dann werde ich das KDE-Repo rausschmeißen und nur noch die 4 Tumbleweeds drin haben.

Code:

#  | Name                                            | Aktiviert | Priorität | URI                                                                                
---+-------------------------------------------------+-----------+-----------+------------------------------------------------------------------------------------
 2 | Packman-openSUSE_Tumbleweed                     | Ja        |   20      | ftp://ftp.uni-erlangen.de/pub/mirrors/packman/suse/openSUSE_Tumbleweed/            
15 | KDE:Extra:openSUSE_Tumbleweed                   | Ja        |   30      | http://download.opensuse.org/repositories/KDE:/Extra/openSUSE_Tumbleweed/          
16 | KDE:Release:47                                  | Ja        |   30      | http://download.opensuse.org/repositories/KDE:/Release:/47/openSUSE_12.1/          
 3 | openSUSE BuildService - GNOME:Anwendungen       | Ja        |   40      | http://download.opensuse.org/repositories/GNOME:/Apps/openSUSE_12.1/               
14 | openSUSE BuildService - GNOME:STABLE:32         | Nein      |   40      | http://download.opensuse.org/repositories/GNOME:/STABLE:/3.2/openSUSE_12.1/        
 4 | openSUSE BuildService - LibreOffice             | Nein      |   70      | http://download.opensuse.org/repositories/LibreOffice:/Stable/openSUSE_12.1/       
 5 | openSUSE BuildService - Wine-CVS-Pakete         | Ja        |   70      | http://download.opensuse.org/repositories/Emulators:/Wine/openSUSE_12.1/           
 7 | openSUSE BuildService - Mozilla                 | Nein      |   70      | http://download.opensuse.org/repositories/mozilla/openSUSE_12.1/                   
17 | openSUSE BuildService - server:php:applications | Nein      |   70      | http://download.opensuse.org/repositories/server:/php:/applications/openSUSE_12.1/ 
18 | libdvdcss repository                            | Ja        |   70      | http://opensuse-guide.org/repo/12.1/                                               
 8 | openSUSE Current OSS                            | Ja        |   80      | http://download.opensuse.org/distribution/openSUSE-current/repo/oss/               
 9 | openSUSE Current non-OSS                        | Ja        |   80      | http://download.opensuse.org/distribution/openSUSE-current/repo/non-oss/           
10 | openSUSE Current updates                        | Ja        |   80      | http://download.opensuse.org/update/openSUSE-current/                              
13 | openSUSE:Tumbleweed:standard                    | Ja        |   80      | http://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/           
 6 | openSUSE BuildService - Spiele                  | Ja        |   90      | http://download.opensuse.org/repositories/games/openSUSE_12.1/                     
12 | openSUSE:Factory:Contrib:openSUSE_121           | Nein      |   90      | http://download.opensuse.org/repositories/openSUSE:/Factory:/Contrib/openSUSE_12.1/

Appleonkel · 29 Nov. 2011

Ja ist doch alles super bei mir, in dem Tumbleweed Repo werden nur neuere Versionen sein als in OSS. Sicherheitsupdates gibt es aus dem Update Repo und Packman kommt auch aus Tumbleweed was ja gegen das standard Tumbleweed linkt.
Und genau das ist die Idee hinter Tumbleweed, das es ein Repo gibt wo die Versionen drin landen die aktueller sind als das was bei Release (OSS) rauskam, von den Paketmaintainern als stabil angesehen werden und nicht so "gefährlich" ist wie Factory.
Da 12.1 ja erst rauskam gibt es natürlich noch nicht viele neuere Pakete.
Zu einem ständigen Herstellerwechsel kann es nicht kommen, das ja alle Pakete aus Tumbleweed in höherer Version vorliegen als OSS.
Und wenn du nochmal auf http://en.opensuse.org/Tumbleweed schaust steht da auch

Add the current openSUSE repositories with enabled autorefresh

Das current im Moment 12.1 ist, sind wir uns doch einig. Also habe ich genau die Repoliste die dort vorgeschlagen wird +Packman-Tumbleweed und meine Python Pakete.

m00nraker · 29 Nov. 2011

Oje, nee, bin nicht ganz einig mit Dir. Ich glaube, Du liegst mit Deinem letzten Post bzw. Deiner Repo-Liste ziemlich daneben. Es folgt eine ausführliche Begründung:

Schau Dir nochmal Deine Repo-Liste an. Zwei gravierende Dinge fallen mir dort sofort auf:

1)
Du hast genau zwei Einträge betreffend Tumbleweed. Einer davon ist ein openSUSE-Tumbleweed Repo. Das ist aber nur eines der insgesamt 4 benötigten openSUSE-Tumbleweed-Repos, die Du hinzufügen müsstest, um ein Rolling-Release ala Tumbleweed zu erhalten. Mach Dir bitte mal die Mühe und öffne den zugehörigen Link in einem Browser damit Du siehst, welche Dateien sich dahinter verbergen: http://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/x86_64/. Du siehst, nur ein paar Git-RPMs liegen dort drin, das war es aber auch. Die wichtigen Dateien liegen in den anderen drei Tumbleweed Repos (current-oss, current-non-oss und current-update), die Du aber bei Dir NICHT hinzugefügt hast. Stattdessen hast Du nur die 3 Standard openSUSE Repos (oss, non-oss und update). Dies ist KEIN Tumbleweed.

Das putzige daran ist, du hast oben selbst zitiert:

http://en.opensuse.org/Tumbleweed hat geschrieben:The only supported method of repo use for Tumbleweed is to have only the main repos (Oss, Non-oss, and Update) AND the Tumbleweed repo active.

Ja, so steht es auf dem Tumbleweed-Portal. Ich denke aber, dort hat sich ein Fehler eingeschlichen oder es ist einfach unglücklich doof ausgedrückt. Es müsste dort nicht AND sondern besser OR im Sinne von XOR heissen: also ... only the main repos (Oss, Non-oss and Update) OR the Tumbleweed repo active.

Wenn Du weiter oben auf der Tumbleweed Portal Seite (http://en.opensuse.org/Tumbleweed) liest steht dort eindeutig:

How to try Tumbleweed?

# Remove the openSUSE 11.4 (or 12.1 or later) version specific repositories
...
# Add Tumbleweed to your YaST or zypper installation repositories and enable autorefresh:

Also: Entweder openSUSE Repos (Oss, Non-Oss und Update) hinzufügen ODER (= XOR) die 4 benötigten Tumbleweed Repos.
Du hast hier aber ein MischMasch, was auch, wenn man drüber nachdenkt, nicht richtig sein kann. Auf Deine Begründung, dass im Tumbleweed immer eine höhere Version liegt, kannst Du Dich nicht 100%tig verlassen. Es sind sicherlich unterschiedliche Maintainer. Denn das normale openSUSE-Update Repo wird ja auch regelmäßig geupdatet. Wer weiss schon, ob beide Repos zeitgleich Aktualisierungen erfahren. Zudem kommt, dass Dein Packman die gleiche Prio hat, so dass es schon alleine dadurch zum PaketPingPong kommen würde-> siehe 2).

2)
Das zweite Problem, was Du Dir mit Deiner Repo-Liste einfängst, ist dies:

Wenn Du Tumbleweed benutzen möchtest, ist Dein Packman-Essential-Tumbleweed Repo schon richtig. Allerdings stört mich dabei die Priorität 99.
Hier ein Beispiel:
Angenommen Du benutzt ein Paket wie k3b, was sowohl in Packman als auch in Tumbleweed oder den normalen openSUSE Repos liegt. Die Packman Variante hat als Besonderheit das mp3-Plugin mit drin. Du hast geschrieben, Du updatest IMMER per zypper dup. Tja, je nach Versionsnummer würde Zypper bei Dir ständig Vendorwechsel durchführen und mal Pakete aus Packman holen und beim nächsten Repo-Update dann wieder gegen Pakete aus Tumbleweed austauschen. Das kann dumme Nebeneffekte haben. Würde k3b in Tumbleweed geupdatet werden und Packman hinkt hinterher, so würdest Du das schnell zu spüren bekommen. Es sei denn, Du pinnst die Pakete manuell. Besser wäre Packman eine höhere Prio zu geben, dann einmal zypper dup für den Vendor-Wechsel und danach fürs daily business zypper update. So aber kommt es zwangsweise zum Paket-PingPong, wie es auf den openSUSE-SDB Seiten erklärt ist. k3b ist hier nur ein Beispiel.

Und:

Da 12.1 ja erst rauskam gibt es natürlich noch nicht viele neuere Pakete.

Da täusch Dich mal nicht. Du hast ja auch die wesentlichen Tumbleweed Repos noch nicht hinzugefügt. Im Tumbleweed wurden schon haufenweise Dateien geupdatet.

Das current im Moment 12.1 ist, sind wir uns doch einig. Also habe ich genau die Repoliste die dort vorgeschlagen wird

Hast Du nicht, siehe oben.

Zum Abschluß: Dies sind die 4 Tumbleweed-Repos:

openSUSE Tumbleweed:standard: http://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/
openSUSE Current OSS: http://download.opensuse.org/distribution/openSUSE-current/repo/oss/
openSUSE Current NON-OSS: http://download.opensuse.org/distribution/openSUSE-current/repo/non-oss/
openSUSE Current Update: http://download.opensuse.org/update/openSUSE-current/

Jetzt sind wir uns einig?

Appleonkel · 29 Nov. 2011

http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/x86_64/?C=M;O=D
sind ja seit dem 11.11 (Release) verdammt viele Pakete hinzugekommen!
Ich bleibe dabei current bezeichnet die aktuelle Version.

http://en.opensuse.org/SDB:Change_from_12.1_to_Tumbleweed#What.3F.21.3F schrieb:
To not force Tumbleweed users to change this by hand on each release the openSUSE sysadmins have created a 'virtual' repository which is always the latest stable release.

Und wenn ich dann lieber von Hand aus 12.1 ein 12.2 mache ist das meine Entscheidung!

Glaub mir oder nicht. Mein System läuft seit Jahren stabil ohne das ich neuinstalliert habe ...

Bei Packman könntest du recht, ich glaube aber daran (und das sagt mir meine Erfahrung), dass die Packmänner eh schneller sind mit dem updaten.

josef-wien · 29 Nov. 2011

Für mich ist http://en.opensuse.org/SDB:Change_from_12.1_to_Tumbleweed eindeutig: Mit 12.1 treten die drei openSUSE-current-Repos an Stelle der bisherigen Repos für OSS, Non-OSS und Update, um nicht immer bei einer neuen release die Repos anpassen zu müssen.

Von meinem Verständnis her sollten bis zum Erscheinen von 12.2 current und 12.1 inhaltlich identisch sein.

m00nraker · 29 Nov. 2011

@AppleOnkel, bevor Du mich jetzt haust:
Hatte schon gepostet, habe mich aber geirrt und musste den Post ändern.

Du hast Recht mit dem Current.

Ich bleibe dabei current bezeichnet die aktuelle Version.

http://download.opensuse.org/distribution/12.1/repo/oss/suse/
und
http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/
sind immer identisch. Dies würde dann auch für non-oss und update so gelten. Current ist sozusagen nur ein Link auf 12.1. Gleiches gilt für non-oss und update.

http://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/ ist also das einzige reale Tumbleweed Repo, wo gegenüber der 12.1 aktualisierte Software drin liegt. Es handelt sich bei current also nur um eine Vereinfachung, dass man beim nächsten Dist-Upgrade die 12.1 nicht manuell durch 12.2 in der Repoliste ersetzen müsste. Ok, nun verstehe ich Dich. Die versionsspezifischen Repos (mit 12.1 im Pfad) könnten also theoretisch drin bleiben, so wie Du es machst, bis eben die nächste Version 12.2 erscheint. Dann musst Du manuell ändern.

Bei Packman könntest du recht, ich glaube aber daran (und das sagt mir meine Erfahrung), dass die Packmänner eh schneller sind mit dem updaten.

Glaube? Ich bin Atheist

. Vielleicht trügt Dich Deine "Erfahrung" da ein wenig. Es ist nicht so, wie Du schreibst. Vielleichst solltest Du den Verbose-Level in Zypper um zwei Stufen anheben (Option -vv), damit Du besser sehen kannst, was Zypper genau updatet bzw. von woher es kommt.

Beweis:
Aktuelles Packman-Tumbleweed-Repo ftp://ftp.uni-erlangen.de/pub/mirrors/packman/suse/openSUSE_Tumbleweed/Essentials/x86_64/
k3b-2.0.2-13.19.x86_64.rpm

Aktuelles openSUSE-Tumbleweed-Repo http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/x86_64/
k3b-2.0.2-18.1.2.x86_64.rpm

Macht es klick? openSUSE-Tumbleweed ist hier aktueller. Ein zypper dup würde dann bei Dir einen VendorChange auslösen. Wird dann Packman geupdatet, kriegst Du wieder einen VendorChange. Das betrifft auch x andere Pakete. k3b dient hier nur als Beispiel. Packman kann nicht in allem aktueller sein, wie kommst Du darauf?

PaketPingPong muss nicht unbedingt dazu führen, dass Dein System nicht mehr bootet und nicht rund läuft. Allerdings gibts nichts an der Sache zu rütteln, dass Du verschiedene Paketquellen auf diese Weise durcheinander würfelst, sprich immer das Paket mit der höchsten Versionsnummer installierst, unabhängig aus welchem Repo es kommt. Dein Python-Repo hat ja eine höhere Prio. Prima, der Python-Kram kommt dann auch daher, so wie von Dir gewünscht. Mit Packman sollte es genauso laufen. Dazu passen die Prios bei Dir aber nicht. Du hast ja geschrieben, dass Du dup anstelle von update verwendest.

Appleonkel · 29 Nov. 2011

Macht es klick? openSUSE-Tumbleweed ist hier aktueller. Ein zypper dup würde dann bei Dir einen VendorChange auslösen.

Würde es?

Code:

huygens:~ # zypper if k3b
Loading repository data...
Reading installed packages...

Information for package k3b:

Repository: packman-essentials
Name: k3b
Version: 2.0.2-13.19
Arch: x86_64
Vendor: http://packman.links2linux.de
Installed: Yes
Status: up-to-date
Installed Size: 14.1 MiB
Summary: A Universal CD and DVD Burning Application
Description: 
K3b is a CD burning application that supports Ogg Vorbis, MP3 audio
files, DVD burning, CDDB, and much more.

huygens:~ # zypper dup
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Loading repository data...
Reading installed packages...
Computing distribution upgrade...

Nothing to do.

Tut es aber nicht

Aber warum weiß ich selber noch nicht :???:
Verbose sagt mir nur das es nicht installiert wird.

m00nraker · 29 Nov. 2011

Jupp, so ist es bei mir auch. Ok, will ja lernen.

Das liegt an k3b-codecs. Habs ausprobiert: k3b und k3b-codecs gelöscht. Dann:

Code:

zypper -vv in k3b
Ausführlichkeitsgrad: 2
Programmargumente ohne Option: 'k3b' 
Ziel wird initialisiert
Es wird überprüft, ob die Metadaten für Packman-openSUSE_Tumbleweed aktualisiert werden müssen.
Es wird überprüft, ob die Metadaten für openSUSE BuildService - Wine-CVS-Pakete aktualisiert werden müssen.
Es wird überprüft, ob die Metadaten für openSUSE BuildService - Spiele aktualisiert werden müssen.
Es wird überprüft, ob die Metadaten für openSUSE Current OSS aktualisiert werden müssen.
Es wird überprüft, ob die Metadaten für openSUSE Current non-OSS aktualisiert werden müssen.
Es wird überprüft, ob die Metadaten für openSUSE Current updates aktualisiert werden müssen.
Es wird überprüft, ob die Metadaten für openSUSE:Tumbleweed:standard aktualisiert werden müssen.
Es wird überprüft, ob die Metadaten für libdvdcss repository aktualisiert werden müssen.
Daten des Repositorys laden ...
Installierte Pakete lesen ...
Auflösung erzwingen: Nein
'k3b-2.0.2-18.1.2.x86_64' aus Repository 'openSUSE Current OSS' für die Installation wählen.
Paketabhängigkeiten auflösen ...
Auflösung erzwingen: Nein

Das folgende NEUE Paket wird installiert:
k3b  2.0.2-18.1.2  x86_64  openSUSE Current OSS  openSUSE

Er nimmt es aus Current. Normal, da dort die höchste Versionsnummer, also noch kein PingPong Effekt. Installierst Du danach die Codecs per zypper in k3b-codecs, kommt es zum Konflikt und es wird u.a. ein Downgrade auf die Packman-Version vorgeschlagen (k3b-2.0.2-13.19)

Ist k3b und k3b-Codecs installiert, bleibt es bei einem zypper dup bei der Packman Version, wegen k3b-codecs. In diesem Fall spielen die Prios tatsächlich keine Rolle. Auch wenn das Beispiel mit k3b nicht ganz passt, ist das Prinzip des PaketPingPong aber schon so. Vielleicht passt es wegen der aktuellen Paketsituation nicht ganz, fügst Du aber z.B. die KDE-Repos (siehe meine Repo-Liste) hinzu, tritt der Effekt häufig auf und läßt sich durch Prioritäten vermeiden.

Es ist aber nicht garantiert, dass dieser Effekt nicht auch bei Packman-Paketen auftritt.

Zypper Prioritäten bei Tumbleweed+KDE und vendor stickyness

Newbie

Hacker

Newbie

Guru

Newbie

Hacker

Newbie

Hacker

Guru

Newbie

Guru

Hacker

Newbie

Hacker

Newbie

Hacker

Ultimate Guru

Newbie

Hacker

Newbie