Danke für die ausführlichen Beispiele!
Danke für den Kommentar!
Naja, es “tut” schon noch etwas: es richtet sich doch tatsächlich nach der Priorität (auch später), aber “Vendor Stickiness” ist eben nicht vorhanden.
In meinem Bsp.:
Ich habe Packman mit Priorität 95 (also erhöht) und die regulären openSUSE Repositories mit Priorität 99 (die weiteren Repositories lasse ich mal außen vor, weil sie nicht mit Packman interagieren).
Wenn ich jetzt davon ausgehe — und das tue ich halt; kann sein, dass genau das mein Fehler ist —, dass die Pakete bei Packman mindestens genauso aktuell sind wie die bei openSUSE Leap (bei mir geht’s um VLC und die entsprechenden Codecs), dann erhält mein System doch eigentlich immer die Packman Pakete?!
Wenn ich versuchsweise bei Packman die Priorität auf 105 setze, will dup auf openSUSE Leap Pakete wechseln. Aber das könnte ich doch mit --no-allow-vendor-change verhindern, oder nicht.
Ich weiß nicht was du mit “es” meinst, aber "später tit das nicht mehr.
Es ist ziemlich nuztlos wenn wir hier mit ja-neinj-ja-nein weiter diskutieren. Also, viel Spaß.
Wir reden jetz über Leap (um Misverständnisse vorzubeugen).
Beide haben ihre eigene Maintainer und ihre eigene Folge von Versionsandeutungen.
Wenn es ein Sicherheits-patch gibt die auch den verstümmelten OSS Version betrifft werden wohl beiden einen Update herausbringen (aber wer ist am ersten derig damit). Wenn das Update aber nur das Packman Produkt betrifft wird es im OSS Update nichts neues geben.
Bitte, zeige uns das.
Nein.
Wegen Tumbleweed wurde ja zypper dup entschärft.
zypper dup macht auch standardmäßig keinen Anbieterwechsel.
Nur mit --allow-vendor-change, welche in der zypp.conf geändert werden kann.
##
## 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
Daher funktioniert die Priorität nur mit noch nicht installierten Programmen, wenn diese installiert werden.
Oder bei neuen Abhängigkeiten eines Paketes, welches upgedated wird, wobei es hier ja dann auch wieder, da neue Abhängigkeiten, als Neuinstallation gilt.
Das sind diese, bei Tumbleweed linken die auf opensuse:factory, allerdings auch mit den damit verbundenen Risiken…
Mein Kommando sieht tatsächlich so aus:
zypper -vvv dist-upgrade --download in-advance --no-recommends --allow-downgrade --allow-name-change --allow-arch-change --allow-vendor-change
Eventuell sorry. In diesem Thread reden “wir” über Leap und Tumbleweed. Es kann sein, dass Du in Deinem Post nur von Tumbleweed geredet hast und ich in dem Moment nicht aufgepasst habe. Dann bitte sorry. Mir geht es ja gerade um die Gegenüberstellung von Tumblweed und Leap…
Genau genommen, nutze ich zypper -vvv dist-upgrade --download in-advance --no-recommends --allow-downgrade --allow-name-change --allow-arch-change --allow-vendor-change und damit wird die Priorität beachtet.
Sorry, dass ich das vorher noch nicht explizit hatte. Ich hatte immer nur von zypper dup geschrieben in Abgrenzung von zypper up oder PackageKit.
Du verwendest da eine ziemlich fragwürdige Kombination an Optionen…aber es ist dein System.
Anscheinend verstehst du das Falsch. Dies ist ein Herausforderung. Du sollst zeigen was passiert wenn du die Priorität von Packman auf 105 setzst und zypper dup machst. Du sagst zwar
Aber wir glauben nur Tatsachen und keine Aussagen über solche Sachen.
Noch immer Blödsin. Es wird nach ASCII sortierten versions Text gearbeitet.
Aber natürlich, man kann mit Optionen Alle Defaults zunichte machen. Wir haben nur
zypper dup
empfohlen. Und das reicht völlig mit Tumbleweed. Alles was du dazugibst kann unwichtig sein (wie z.B. -vvv ), aber auch das ganze frustrieren.
Du wirst warscheinlich staunen, aber vor ein (oder zwei?) Jahr sollte das nog sein
zypper dup --no-allow-vendor-change
Da aber viele Leute das nicht gelesen haben ist dann --no-allow-vendor-change als Default eingebaut worden.
Und jetz frustrierst du das mit '–allow-vendor-change` .
Und, das schlimmste, du erklärt uns nichts davon und wir stochern im Dunklen herum. Danke schön.
OK, also noch einmal der Übersicht halber…
Ich habe insgesamt drei Systeme: Leap, Tumbleweed und Slowroll.
Bei Tumbleweed und Slowroll sind außer den Standard-Repositories (99) nur noch Packman, und das mit Priorität 95.
Bei Leap sind außer den Standard-Repositories eine Reihe weiterer Repositories, weil teilweise die Pakete in Leap (beim Standard) gar nicht enthalten sind oder ich sie teilweise gerne etwas aktueller (z.B. Mozilla Firefox und Thunderbird) bzw. in einem bestimmten Versionsstand (LibreOffice im Zweig 7.5, dort die letzt-aktuelle Version, das wäre 7.5.9.2) hätte.
Packman hat auch hier 95, die Standard-Repositories 99 (default), einige Repositories 95, einige 105, einige 99.
Bei Tumbleweed und Slowroll setze ich in der Tat zypper dup (dieser String) ein — und manchmal kommt mir Yast/PackageKit zuvor, wenn ich mich zwischendurch nicht regelmäßig auf der Konsole einlogge und manuell dort das Update anstoße. Bisher noch ohne Probleme.
Bei Leap nutze ich teils Yast/PackageKit, teils zypper -vvv dist-upgrade --download in-advance --no-recommends --allow-downgrade --allow-name-change --allow-arch-change --allow-vendor-change.
Meine Frage war die Gegenüberstellung der Updatemethoden (für alle Systeme).
Dass ich bei Tumbleweed (und somit vermutlich auch Slowroll) besser zypper dup als Yast/PackageKit nehmen soll, hat sich mir dank @Sauerland mittlerweile einigermaßen erschlossen.
Aber mir war/ist bisher noch nicht ganz klar, warum ich bei Leap unbedingt zypper dup (bzw. in meinem Fall den entsprechenden langen String) vermeiden soll und stattdessen nur Yast/PackageKit nehmen solle. Aber wenn es denn tatsächlich so ist, kann ich mich gerne daran halten.
Zur Klarstellung: ich habe Mathematik studiert (und auch erfolgreich abgeschlossen), aber ich bin kein IT-Profi i.A. oder Linux-Profi i.B. Ich nutze Linux (openSUSE) als mein tägliches Desktop System… und fertig.
Und weiter: dieser Thread im Besonderen und Kommunikation i.A. wächst in der Regel “organisch”. Natürlich wäre es schöner, wenn ich bereits ganz am Anfang wüsste, auf welche zu nennenden Details es alles ankommt etc.
Ich wollte @hcvv nicht unnötig “ärgern”. Aber die Beiträge von @Sauerland erscheinen mir (persönlich) wesentlich konstruktiver und auch freundlicher.
An @hui noch die Frage: was ist denn an zypper -vvv dist-upgrade --download in-advance --no-recommends --allow-downgrade --allow-name-change --allow-arch-change --allow-vendor-change so “schlimm”? Ist da etwas ernsthaft falsch? Ich frage ganz naiv, aber interessiert… Die einzelnen Schalter und ihre Bedeutung kenne ich jeweils. Aber sind die tatsächlichen Belegung (--allow- im Gegensatz zu --no-allow-`) und die gesamte Kombination unsinnig?
Wenn du dich mit den settings in zypp.conf und zypper.conf beschäftigst, wirst du feststellen, das du unsinnigerweise die Standardeinstellungen wiederholst…
--allow-downgrade --allow-name-change --allow-arch-change --allow-vendor-change sind Standardeinstellungen…
In /etc/zypp war ich bisher noch nie manuell (mit einem Editor) unterwegs. Nur an wenigen anderen Stellen.
Ich habe mir gerade zypp.conf und zypper.conf per less angesehen. Ja, das scheinen tatsächlich Standardeinstellungen zu sein. — Allerdings steht bei mir als Ausnahme doch solver.dupAllowVendorChange = false. Keine Ahnung, wo das ursprünglich herkommt. Aber wohl deswegen scheine ich dem String zypper dup vor Jahren mal --allow-vendor-changehinzugefügt zu haben. Und die restlichen Angaben einfach der Vollständigkeit halber (damit ich sie sehe — ungeachtet des Standardwertes).
Dir hatte ich noch nicht Danke gesagt!
Auch sehr reichhaltiger und interessanter sowie informativer Beitrag.
Das Dilemma mit Plasma hatte ich in den Medien mitbekommen. Da dachte ich, bin ich mit Xfce halbwegs auf der sicheren Seite (weil es dort nicht so große Sprünge gibt). Ansonsten habe ich zwar einige zusätzliche Repositories bei Leap (aus Gründen), aber insgesamt eine recht überschaubare Paketauswahl, und ich lasse keine Server-Dienste laufen.
Zumindest --allow-vendor-change ist schon seit Jahre(n) auf false.
Siehe meinen Beitrag und auch C7NhtpnK
grep -i 'allowvendor' /etc/zypp/zypp.conf
# solver.allowVendorChange = false
solver.dupAllowVendorChange = false
Danke an alle Teilnehmer! (Das Thema kann geschlossen werden. Ich wollte nur nicht einen bestimmten Beitrag als Lösung markieren.)
So geht das: Noninteractive System Upgrades
Ein paar Zeilen genügen: Tumbleweed zypper dist-upgrade as a systemd service - openSUSE Wiki
1 Like
Cool, Danke, @karlmistelberger !
Am Anfang hatte @susejunky schon auf Deine Beiträge hingewiesen, Danke trotzdem für den expliziten Kommentar.
Frage: läuft das denn bei Dir tatsächlich problemlos (offensichtlich schon) — wenn so viele andere darauf hinweisen, lieber manuell und nur nach ernsthafter Prüfung zu updaten (zypper dup)?
Der Befehl von @karlmistelberger hat aber keine Fehlerabfragen, wenns mal nicht funktioniert…
Würde ich persönlich nicht benutzen.