Änderung der Repo URL bei Veröffentlichung Leap 15.2

Zitat von tux93

Um den Repocache für die neue Version zu bauen

Code

zypper --releasever 15.2 dist-upgrade

Teil 1 funktioniert wunderbar, Respekt!

ABER nach manueller Behebung der Abhängigkeiten und maximal den Benutzer nerven (ist eine ganz üble Linuxkrankheit aus den rpm-Anfangszeiten SuSE6.0++) - es fehlt da die Auswahloption "FUS&Quit"

dann kommt "Note: System reboot required" (bin ich jetzt Engländer?) und dann "agree license bla bla" - sagt er trotz "yes" GARNICHTS mehr, keine Fortschrittsanzeige, keine Fehlermeldung, aber er blockiert heftig die Paketverwaltung und zwar dermaßen, daß man auch mit Yast nicht mehr weiterkommt nur mit kill und pid und - arrrgh

Wieso kann man nicht einfache und nachvollziehbare Lösungen mit Eingabefeld und Fortschrittsanzeige vorsehen und im Yast eine Pfadeinstellung vorsehen, notfalls mit warnender Quittung "Expertenmodus bla bla"? Das ist alles halbrussisch. Schon nach dem ständigen gesudoe hab ich Puls.

Wir alle wissen, die Linux und Windows kennen, daß auch wenn im Innern von Windows die Hölle tobt und nichts wirklich 100% sauber abläuft - der Windowsprogrammierer hütet sich davor den Nutzer zu nerven oder etwa mitzuteilen, daß es ein Problem gibt - eher wird im Hintergrund ein Speicherauszug erstellt und dem Entwickler heimlich ein Bugreport gesendet als das irgendwo ein Fenster aufgeht wo was anderes draufstehlt als "OK" oder "Abbrechen" - aber das ist schon grenzwertig.

Irgendwo zwischen den Linuxfehlerromanen und dem "Schweigen von Windows" (Oscar-verdächtig) liegt das gewollte Optimum.

Nach einer gefühlten Stunde (in der Miitagspause) und bereits der Verzweiflung nahe - kommen die ersten Ausgaben Retrieving ...

Ich lasse es mal weiterlaufen und "cross the finger" hoffe es zerschiest mir nicht die einigermaßen mit Krücken lauffähige 15.1.

Ändert nichts an der Tatsache, daß hier eine generelle und saubere Lösung gebraucht wird, die Abhängigkeiten nach dem "Haufenprinzip" untereinander passfähiger rpm's auflöst und dann eine Plane drüber auf der steht "Alles warm, trocken, sicher und in Ordnung mit der 15.2" - der Rest unter der Plane wird gemacht wenn das nächste Update kommt. Bei "akuter Gefahr" wird die Gefahrstellestelle gefixt (minor update 15.2.1) und wieder eine Plane drüber. So muss das laufen - nicht so arbeiten wie die Bundesregierung, alles blind anfassen und dann nichts sauber fertig kriegen.

Resultat nach vielen Stunden "Retrieving.." es geht so nicht - zumindest nicht sauber!

Es erscheint "Checking for file conflicts" und am Ende bekommt man ein inkonsistentes System mit der fatalen Auswahl aus mehreren Paketen Files gleichen Namens mit unterschiedlichem Inhalt überschrieben zu bekommen.

Als SuSE von tgz-Tarballs (force = last tgz wins) zu RPM wechselte und diese Paketinkompatibiläten anfingen einem dem letzten Nerv zu rauben, da hatte ich gesagt:

"RPM ist prinzipiell eine gute Idee, aber diese Idee wurde nicht zu Ende gedacht, da es keinen automatischen Prozeß gibt, der Paketabhänigkeiten ohne Zutun des Nutzers in jedem Fall automatisch auflöst, notfalls an den Punkt zurückkehrt wo es das letzte mal 100% funktioniert hat."

Das KI-Problem dahinter hat damals keiner verstanden, aber ich habe damit Recht behalten - RPM ist halbrussisch solange das Thema nicht streng deterministisch gelöst ist ohne manuellen Pflegeaufwand und das geht nicht ohne interne automatische Prüfung durch den Paketmanager auf der Linker-Ebene welche Datei zu welchen Symbolen oder Hardware Beziehungen in welcher passfähigen Version aufbaut.

Das muss bereits beim Linken für den Paketbau automatisch erfasst werden, denn später geht es nicht mehr aufzudröseln ohne manuellen Eingriff weil die dafür nötige Information nach dem Linken nicht mehr vorhanden ist. Es geht dann irgendwie oder es kracht und genau dann sind wir wieder auf dem Level von tgz.

Das noch schwierigere Unterproblem dazu wäre (bei debian-System massives Problem): Wie kann der Nutzer mit wenigen EIngaben eine für bestimmten Zuschnitt (reiner Server, Desktop, Entwicklerarbeitsplatz usw) eine 100% funktionierende Grundinstallation bekommen, die mindestens die Pakete enthält, die er im vorherigen System bei sich auch manuell nachinstalliert hat (mc, fte, emiclock usw) die aber nicht zwingend einer Kategorie zugeordnet werden können, ebenso wieder ohne Paketkonflikte und wieder alles ohne manuellen Pflegeaufwand.

konnte auch ein dist-upgrade mit Hilfe der Infos hier machen

nun sind die folgenden repos aktiv:

linux-lykr:/home/pmu/Downloads/display # zypper repos --uri
Repository priorities are without effect. All enabled repositories share the same priority.

#  | Alias                     | Name                               | Enabled | GPG Check | Refresh | URI
---+---------------------------+------------------------------------+---------+-----------+---------+-------------------------------------------------------------------------
 1 | dvd                       | dvd                                | Yes     | (r ) Yes  | Yes     | http://opensuse-guide.org/repo/openSUSE_Leap_15.1/
 2 | openSUSE-Leap-15.1-1      | openSUSE-Leap-15.1-1               | No      | ----      | ----    | http://download.opensuse.org/distribution/leap/15.1/repo/oss/
 3 | openSUSE-Leap-15.2-1      | openSUSE-Leap-15.2-1               | Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/distribution/leap/15.2/repo/oss/