Tumbleweed/Slowroll: wie updaten? Zwingend zypper dup?

Hallo,

ich habe insgesamt drei openSUSE System:

  • 1× Leap (15.5)
  • 1× Tumbleweed
  • 1× Slowroll

Für Updates benutze ich innerhalb von Leap den internen Paketupdater. Meistens jedenfalls. Ab und zu logge ich mich auch mal in die Konsole ein und mache zypper dup.

Für Tumbleweed und Slowroll nutze ich i.d.R. die Konsole mit zypper dup. Aber den internen Paketupdater habe ich nicht vollständig gelöscht/deaktiviert. Ab und zu wird auch darüber ein Update gemacht. Nur allermeistens komme ich dem mit zypper dupzuvor.

Ich habe gehört/gelesen, dass zypper dupder bevorzugte Weg, bzw. der “richtige”, ist. Ohne bisher zu wissen, warum unbedingt. OK, bei upwerden viele Patches eingespielt, bei dupganze Pakete. Und es gibt andere Abhängigkeitsauflösungen bei dup. Aber mir war bisher noch nicht ganz klar, warum dupzwingend, und upschädlich sein sollte.

In einem anderen Thread wurde jetzt auf zypper dup Problematik verwiesen.

Hat da noch jemand Ergänzungen oder weitere Hinweise? Also z.B. ob man up eventuell auch nehmen könnte, ohne allzu viel kaputt zu machen. Und vor allem würde mich interessieren, wie man zypper dupautomatisieren könnte (wenn überhaupt möglich). Ich möchte mich nicht einmal täglich an der Konsole statt in der GUI anmelden. Kann man das per chronoder systemdmachen — wenn ja, wie?

Ich bin nur ein Anwender, kein Profi… Deswegen frage ich so naiv. Sorry, wenn sich hier jemand daran stört…

Das ist also Flasch. Bei Leap sollte man zypper dup nur benutzen wenn man zur nächste Version geht (z.B. 15.5 > 15.6). Oder bedingt für angemessene Aktionen (mit z.B. --from packman wenn man Pakete auf andere Repos wechseln möchte).

Das sollte nicht nur in die allermeiste Fälle gemacht werden, aber immer. Was du “internen Paktupdater” nennst, kann höchstens darauf aufmerksam machen das ein neuses Snapshot da ist. Sonst Finger weg davon.

M.M.n. sollte man sowas überhaupt nicht tun wollen. Bei einen neue Tumbleweed Snapshot sollte man erst mal Überprüfen was da drin ist. Das haben z.B. vielen vergessen und, Überraschung, da war KDE PLasma 6 drin. Da möchte man das vielleicht eins oder zwei Tage vor sich her schieben. Im Forum schauen ob Andern Probleme haben. Nicht wenn man gerade einen wichtigen Termin hat. U.s.w.

Wenn du das einmal in der Woche machtst reicht das meiner Einsicht nach völlig. Und übrigens werden die Spapshots hier im Forum > English > News und Announcemnts angekündigt. Und auch wird man geraten sich den Tumbleweed Mailngliste an zu schließen.

Das funktioniert schon mit einem Script, aber man sollte dort auchn Fehlermeldungen und Fehler abfangen.
Wird so bei dem Mann einer guten Freundin gemacht, da wird dann auch ein Fehlercode zurückgegeben, anhand dessen kann man dann schauen, was schief gelaufen ist.

Nicht ganz so trivial.

Tumbleweed benutzt so weit ich weiß keine patches.

Daher kann das updaten per GUI lange gutgehen, aber irgendwann fällt es dir ganz schwer vor die Füße.

Am besten die GUI nur als Anzeige benutzen und dann per Konsole und
zypper dup
updaten

Bist Du Dir sicher, dass openSUSE Tumbleweed dann das für Dich geeignete System ist? Hast Du das hier gelesen?

Ansonsten, wenn Du (als “Anwender”) der Meinung bist automatisierte Aktualisierungen (und die dabei eventuell auftretenden Komplikationen) handhaben zu können, dann suche im englischsprachigen Teil des Forums nach Beiträgen von @karlmistelberger . Der beschreibt, wie man mit Hilfe eines systemd-service und eines systemd-timers openSUSE Tumbleweed automatisiert aktualisieren kann.

Hallo!

Danke Dir!

Ja, den verlinkten Artikel kenne ich bereits. Prinzipiell weiß ich um das Konzept von Tumbleweed und ein paar mögliche Gefahren.

Auf meinem Hauptsystem setze ich auch tatsächlich Leap ein. Aber ich möchte es teilweise etwas aktueller haben und dabei weniger zusätzliche Repositories einbinden müssen (bei Leap muss ich doch einige Repositories einbinden, damit alles so ist, wie ich es haben möchte — manche Pakete sind sonst noch nicht einmal überhaupt verfügbar, die aber bei Tumbleweed direkt dabei sind). Andererseits sind meine Systeme (auch Tumbleweed und Slowroll) längst nicht so vielschichtig, dass ich das Risiko gerne eingehe. Zumal ich oft viele Berichte von vielen Usern lese, die ihre regulären Produktiv-Systeme mit Tumbleweed laufen lassen. Jedenfalls nutze ich selbst keinerlei Server-Dienste, habe als Desktop Xfce, und meine Auswahl an Anwendungen insgesamt ist recht überschaubar (ich versuche die Anzahl installierter Pakete gering zu halten — trotzdem habe ich mit den von mir ausgesuchten Programmen unter Leap das Problem, dass ich einige Repositories einbinden muss). Ich habe jetzt kein wirkliches Minimal-System, aber es ist wirklich reduziert. Da finde ich den Einsatz von Tumbleweed/Slowroll doch vertretbar. Und mit Xfce als Desktop habe ich ja auch ein anderes Kaliber (also eigentlich kein “Kaliber”) als KDE/Plasma. Um noch etwas stabiler zu sein, finde ich ja gerade Slowroll so spannend. Ich überlege tatsächlich, alle Systeme mit Slowroll zu betreiben. Und dann würde ich auch mal nach den von Dir angesprochenen Beiträgen gucken. Das könnte ein ganz guter Mittelweg für mich sein.

Zum Thema Probleme: ich hatte es doch tatsächlich unter Leap, dass vor einer Weile mal (ich weiß nicht mehr, wann genau, vielleicht vor ¼ oder ½ Jahr) ein fehlerhafter Kernel als Update ausgerollt wurde. Da hatte ich mich kurz gewundert, dass mein System nicht mehr booten wollte, aber dann habe ich halt eine Version davor genommen. Ich denke, ansonsten setze ich nicht so viele / so welche Pakete ein, bei denen mit ganz großen Breaks bei Updates zu rechnen ist. Manchmal (recht selten) gibt es einzelne Konflikte oder ähnliche Probleme, aber die habe ich selbst bei Leap (dort zeigt mir der interne Paketupdater eine Liste von Updates an, die er aber insgesamt nicht abarbeiten kann. Mit zypper dup läuft es dann — im Gegensatz zum Paketupdater, also dort nutze ich auch teilweise zypper dup was ich eigentlich vermeiden möchte).

Der wurde aber kurz darauf von openSUSE zurückgezogen:

vR | kernel-default                    | Paket      | 5.14.21-150500.55.22.1               | x86_64 | Update repository with updates from SUSE Linux Enterprise 15

Man beachte das vR, siehe:
man zypper

Noch einmal:
Bei Leap bitte nur das Update Applet unten rechts verwenden, das macht dann einen
zypper patch
Wenn dies Applet einen Fehler meldet, dann bitte in der Konsole
zypper up

zypper dup

bitte bei Leap nur für einen Repowechsel benutzen, der Befehl ist zwar schon entschärft, aber besser gar nicht erst angewöhnen.

Es ist Deine Entscheidung …

https://forums.opensuse.org/t/do-i-have-to-babysit-updates-and-other-questions-from-a-new-user/172346/12

https://forums.opensuse.org/t/tumbleweed-noninteractive-distribution-upgrade-20221227-0-20240329-0/173787

Ich nutze seit ein paar Jahren auf allen meinen Systemen openSUSE Tumbleweed und führe Aktualisierungen nur “unter Aufsicht” durch.

Aber wie bereits gesagt, es ist Deine Entscheidung …

Naja, sicher, “meine” Entscheidung… — Aber da Du wirklich ernsthaft mahnende Worte hast, werde ich keinen Schnellschuss machen, sondern es mir noch einmal überlegen.

Ich bin bloß in Versuchung, weil ich von so vielen Leuten lese, die Tumbleweed (Slowroll gibt es ja noch nicht so lange und ist kaum bekannt) als reguläres System einsetzen und offensichtlich gute Erfahrungen gemacht haben.

Da war es bereits zu spät: Kernel bereits installiert und neu gebootet (bzw. versucht). Aber wie gesagt, es hatte sich ja geklärt.

OK. Habe ich nun “verstanden”. Also “verstanden”, im Sinne, dass ich es sehr oft wahrgenommen habe. Aber wirklich wissen, warum man bei Tumbleweed unbedingt zypper dupnehmen soll und wiederum bei Leap unbedingt nicht, erschließt sich mir eigentlich immer noch nicht so ganz… Sorry, dass ich da so naiv nachfrage. Bisher hat bei mir beides wechselseitig immer noch funktioniert. Reines Glück? Oder möglich, aber nicht offiziell vorgesehen? Ich wäre wirklich einmal an den tatsächlichen Hintergründen interessiert. (Ich hätte da intuitives Halbwissen, aber wirklich klar ist es mir nicht…)

Aus man zypper:

update (up) [options] [packagename]...
           Update installed packages with newer versions, where possible.

           This command will not update packages which would require change of package vendor unless
           the vendor is specified in /etc/zypp/vendors.d, or which would require manual resolution of
           problems with dependencies. Such non-installable updates will then be listed in separate
           section of the summary as "The following package updates will NOT be installed:".

           To update individual packages, specify one or more package names. You can use the * and ?
           wildcard characters in the package names to specify multiple packages matching the pattern.

dist-upgrade (dup) [options]
           Perform a distribution upgrade. This command applies the state of (specified) repositories
           onto the system; upgrades (or even downgrades) installed packages to versions found in
           repositories, removes packages that are no longer in the repositories and pose a dependency
           problem for the upgrade, handles package splits and renames, etc.

           If no repositories are specified via the --from option, zypper will do a global upgrade
           with all defined repositories. This global form of dup will also consider unchanged
           installed packages and re-evaluate their dependencies. This can be a problem if the system
           contains conflicting repositories, like repositories for two different distribution
           releases. This often happens if one forgets to remove an older release repository after
           adding a new one, say openSUSE 13.1 and openSUSE 13.2.

           For all repositories which have the distribution version within their URL (like
           https://download.opensuse.org/distribution/13.1/repo/oss) using the $releasever variable
           instead may be helpful (https://download.opensuse.org/distribution/$releasever/repo/oss).
           The variable is per default substituted by the current distributions version (13.1).

           This value can be temporarily overwritten in the current zypper command by using the
           --releasever global option. Calling zypper --releasever 13.2... will cause these repos to
           use the new location (https://download.opensuse.org/distribution/13.2/repo/oss) without the
           need to add/remove anything. But you’ll need to use --releasever 13.2 with every zypper
           command until the distribution upgrade was actually performed. Once the dup is done,
           $releasever will default to the new distribution version 13.2 and --releasever is no longer
           needed.

           It might be less tedious to persistently set $releasever to the target distribution value,
           so --releasever is not needed at all. See section Repository Management for more info about
           variable substitution and the definition of custom variables.

           Note: Performing a distribution upgrade will automatically create a solver test case at
           /var/log/updateTestcase-YYYY-MM-DD-hh-mm-ss (the date and time the command was executed).

           Note: distribution upgrades in openSUSE are currently only supported between consecutive
           releases. To upgrade multiple releases, upgrade each consecutive release one at a time. For
           more details see http://en.opensuse.org/SDB:System_upgrade and the openSUSE release notes
           at http://doc.opensuse.org/release-notes/.

Leap stellt die Updates über die Updates Repos ein, diese Updates werden nicht gelöscht, d.h. man kann immer auf eine ältere Version zurückschwenken.

Tumbleweed löscht immer das komplette OSS Repo bzw. die alten Pakete und ersetzt diese mit den neuen Versionen. Somit kann man nicht mehr die alten Pakete installieren.
Daher ist Tumbleweed immer eine neue Distribution, siehe auch das große Upgrade auf KDE6.

Has du denn schon die Dokumentation studiert? Du kannst nicht erwarten das wir, besonders dir, man zypper und weitere Dokumenten vorzeigen. Du kannst hier fragen wenn du da was findest und nicht verstehst. Leute auf Foren für Software helfen nur wenn man so weit wie möglich sich selbts geholfen hat.

Lese auch mal Wie man Fragen richtig stellt: eine Anleitung wie man Fragen erfolgreich in Usenet, Mailinglisten und Webforen stellt. .
Das ist zwar nicht 100% richtig hier, aber gibt viel Hintergrunfinformation in unsere wunderbare Welt.

Danke!

Die Doku hatte ich bereits gelesen… — Aber ich bin mit trotzdem noch unsicher.

Ich kann ja durchaus nachvollziehen, warum bei Tumbleweed zypper dup zu benutzen ist. — Aber mir erschließt sich immer noch nicht, warum man es bei Leap vermeiden soll. Ich kann ja verstehen, dass es nicht der vorgesehen und übliche Weg ist… Aber warum soll man es angeblich unbedingt vermeiden? Ich habe bei mir bisher noch keine Fehler oder Schäden beobachtet.

Danke!

Die von @Sauerland angesprochende Doku und einige weitere Artikel habe ich bereits gelesen. Aber es hat sich mir trotzdem nicht erschlossen… Sorry! (Ich bin zur Schule und zur Uni gegangen. Da habe ich auch viel “Doku” gelesen. Aber wenn ich es dann nicht verstanden habe — trotz Nachdenken(!) — dann habe ich ja auch gefragt…)

Für mich klingt das so wie: Ich quere die Straße immer mit geschlossenen Augen, aber ich lebe noch immer.

Versuche das zu verstehen. Mit zypper dup könnte man z.B. die Wechsel auf Packman zunichte machen weil die Version eines Paketes höher zu sein scheint in OSS. Du hast aber (warscheinlich) absichtlich auf Packman gewechselt.

Das finde ich jetzt ehrlich gesagt etwas albern.

Ich habe bei Leap für bestimmte Repositories extra die Priorität angepasst (teils erhöht, teils erniedrigt, teils auf Standard belassen). (Es gab früher mal ein bestimmtes Paket, das Projekt wurde gut maintained, aber das Paket war zwischendurch buggy, da habe ich eine Zeitlang extra eine ältere Version gewählt und ein Block gesetzt.)

Priorität ist nur wichtig wenn man ein Paket installiert das noch nicht installiert ist. Später tut es nichts mehr. Vendor Stickiness ist was dafür sorgt das bei Updates nicht wieder den Vendor gewechselt wird. Aber Distribution Update schaltet Vendor stickiness aus.

Hier Leap 15.5:

zypper dup
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Warnung: Sie sind im Begriff, eine Distributionsaktualisierung mit allen aktivierten Repositorys durchzuführen. Vergewissern Sie sich, dass diese Repositorys kompatibel sind, bevor Sie fortfahren. Weitere Informationen zu diesem Kommando finden Sie unter 'man zypper'.
Distributions-Aktualisierungen werden verarbeitet...

Problem: 1: Problem mit dem installierten mumble-1.5.629-lp155.219.1.x86_64
 Lösung 1: mumble-1.4.287-bp155.1.10.x86_64 von Hersteller openSUSE installieren
und mumble-1.5.629-lp155.219.1.x86_64 von Hersteller obs://build.opensuse.org/home:Sauerland ersetzen
 Lösung 2: veraltetes mumble-1.5.629-lp155.219.1.x86_64 beibehalten

Wählen Sie aus den obigen Lösungen mittels Nummer oder brechen Sie (a)b [1/2/a/d/?] (a): a

zypper up
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

Die folgenden 2 Objekte sind gesperrt und werden durch keine Aktivität geändert:
 Verfügbar:
  openSUSE-repos-Leap openSUSE-repos-Leap-NVIDIA

Die folgenden 6 Paketaktualisierungen werden NICHT installiert:
  faad2 libappindicator3-1 libfaad2 libfdk-aac2 libxine2-pulse typelib-1_0-AppIndicator3-0_1
Keine auszuführenden Aktionen.

Jetzt schauen wir einmal bei mumble:

zypper se -s mumble
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name                    | Type  | Version             | Arch   | Repository
---+-------------------------+-------+---------------------+--------+-----------------
   | demumble                | Paket | 1.2.2-bp155.2.11    | x86_64 | Haupt-Repository
   | demumble-debuginfo      | Paket | 1.2.2-bp155.2.11    | x86_64 | Debug-Repository
   | demumble-debugsource    | Paket | 1.2.2-bp155.2.11    | x86_64 | Debug-Repository
i+ | mumble                  | Paket | 1.5.629-lp155.219.1 | x86_64 | (Systempakete)
v  | mumble                  | Paket | 1.4.287-bp155.1.10  | x86_64 | Haupt-Repository
   | mumble-debuginfo        | Paket | 1.4.287-bp155.1.10  | x86_64 | Debug-Repository
   | mumble-debugsource      | Paket | 1.4.287-bp155.1.10  | x86_64 | Debug-Repository
   | mumble-server           | Paket | 1.4.287-bp155.1.10  | x86_64 | Haupt-Repository
   | mumble-server-debuginfo | Paket | 1.4.287-bp155.1.10  | x86_64 | Debug-Repository

Warum will dup jetzt mumble aus einem anderen Repo installieren?
Weil es als Systempaket gekennzeichnet ist, das sind Pakete die in keinem der eingebundenen Repos vorhanden sind.
Das installierte mumble ist aus meinem Repo installiert, ich habe es aber in dem Repo gelöscht.

zypper if mumble
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...


Informationen zu Paket mumble:
------------------------------
Repository         : @System
Name               : mumble
Version            : 1.5.629-lp155.219.1
Arch               : x86_64
Anbieter           : obs://build.opensuse.org/home:Sauerland
Installierte Größe : 11,0 MiB
Installiert        : Ja
Status             : aktuell
Quellpaket         : mumble-1.5.629-lp155.219.1.src
Upstream-URL       : https://www.mumble.info/
Zusammenfassung    : Voice Communication Client for Gamers
Beschreibung       : 
    Low-latency, high-quality voice communication for gamers. Includes game
    linking, so voice from other players comes from the direction of their
    characters, and has echo cancellation so the sound from your loudspeakers
    won't be audible to other players.

Jetzt stehe ich vor der Frage, welches mumble ich benutzen möchte…

Jetzt hab ich mumble in meinem Repo wieder gebaut und nun:

zypper dup
Metadaten von Repository 'Sauerland-OSS' abrufen .........................................................................................................................................................[fertig]
Cache für Repository 'Sauerland-OSS' erzeugen ............................................................................................................................................................[fertig]
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Warnung: Sie sind im Begriff, eine Distributionsaktualisierung mit allen aktivierten Repositorys durchzuführen. Vergewissern Sie sich, dass diese Repositorys kompatibel sind, bevor Sie fortfahren. Weitere Informationen zu diesem Kommando finden Sie unter 'man zypper'.
Distributions-Aktualisierungen werden verarbeitet...

Die folgenden 2 Objekte sind gesperrt und werden durch keine Aktivität geändert:
 Verfügbar:
  openSUSE-repos-Leap openSUSE-repos-Leap-NVIDIA

Das folgende Paket wird aktualisiert:
  mumble

1 Paket wird aktualisiert.
Gesamtgröße des Downloads: 4,4 MiB. Bereits im Cache gespeichert: 0 B. Nach diesem Vorgang wird kein zusätzlicher Speicherplatz belegt oder freigegeben.

Backend:  classic_rpmtrans
Continue? [j/n/v/...? zeigt alle Optionen] (j): n

zypper up
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

Die folgenden 2 Objekte sind gesperrt und werden durch keine Aktivität geändert:
 Verfügbar:
  openSUSE-repos-Leap openSUSE-repos-Leap-NVIDIA

Die folgenden 6 Paketaktualisierungen werden NICHT installiert:
  faad2 libappindicator3-1 libfaad2 libfdk-aac2 libxine2-pulse typelib-1_0-AppIndicator3-0_1

Das folgende Paket wird aktualisiert:
  mumble

1 Paket wird aktualisiert.
Gesamtgröße des Downloads: 4,4 MiB. Bereits im Cache gespeichert: 0 B. Nach diesem Vorgang wird kein zusätzlicher Speicherplatz belegt oder freigegeben.

Backend:  classic_rpmtrans
Continue? [j/n/v/...? zeigt alle Optionen] (j): n

Jetzt wäre es egal ob dup oder up.

Du siehst, es kommt immer auf den Einzelfall an.
Daher für mich grundsätzlich:
Leap: zypper up oder zypper patch
Tumbleweed: zypper dup

Für mich persönlich ist openSUSE Tumbleweed zur Zeit die Distribution der Wahl.

Allerdings sollte sich jede(r), die/der openSUSE Tumbleweed für ihre/seine tägliche Arbeit nutzen will, bezügliche einiger Sachverhalte im Klaren sein:

  • Jeder Snapshot stellt einen eigenen Release dar.

  • Die Paket-Versionen eines Snapshots sind sehr aktuell und jeder Snapshot wurde “nur” automatisiert (openQA) getestet.

  • Um die Aktualität der Distribution aufrecht zu erhalten, ist die Aktualisierungsfrequenz hoch (z.Zt. meist 7 Snapshots pro Woche, dabei können ggf. mehrere Tausend Pakete mit einem Snapshot aktualisiert werden).

Nach meiner Erfahrung erfordert der Betrieb von openSUSE Tumbleweed ein gewisses Maß an Bereitschaft (und Zeit) sich mit der Art und Weise, wie das System arbeitet und wie es weiter entwickelt wird, auseinander zu setzen (z.B. Lesen der openSUSE Factory Mailingliste).

Das Beispiel von @hcvv ist garnicht so übel:

Ich führe meine Aktualisierungen mit zypper dup immer in einer Plasma-Konsole aus. Beim Wechsel von Plasma5 zu Plasma6 hat mir das dann eben 10 Minuten unnötige Mehrarbeit beschert.

Natürlich kannst Du rpm, zypper, packagekit, YaST, Discover, … nutzen, um Pakete in openSUSE Leap und/oder Tumbleweed zu aktualisieren. Wenn Du jedoch nicht genau verstehst, wo die Grenzen dieser Werkzeuge im Bezug auf die Anforderungen der jeweiligen Distribution liegen, dann kannst Du “überfahren” werden.

Nutzt Du hingegen die von den Entwicklern empfohlene Vorgehensweise (zypper dup bei Tumbleweed), dann querst Du die Straße an der grün zeigenden Fußgängerampel sehr wahrscheinlich unversehrt.

Wann Du von der Empfehlung abweichen kannst/darfst, das wirst Du nicht durch nachfragen herausfinden können, denn das hängt immer von Deiner Erfahrung, Deinem Kenntnisstand, Deiner Risikobereitschaft und letztendlich auch von Deinen Anforderungen an die Verfügbarkeit Deiner Systeme ab.

Viele Grüße

susejunky