Ich habe seit einiger Zeit mein System mit zypper dup --allow-vendor-change geupdatet. Das hat eine Weile auch gut funktioniert, allerdings stelle ich in letzter Zeit doch häufiger Instabilitäten fest (nicht-aufwachen aus dem Standby oder dunkler Bildschirm nach dem Login). Ich würde daher gern alle Pakete, die einen Anbieterwechsel hatten, auf die Standard-openSuSE-Repos zurückswitchen, sofern sie dort angeboten werden.
Welche Vorgehensweise empfehlt ihr?
Hast du denn überhaupt andere Repos als das was du Standard nennst? Eine Liste wäre wohl von nützen für andere Leute.
zypper lr -d
xxx@yyy:~> zypper lr -d
# | Alias | Name | Enabled | GPG Check | Refresh | Priority | Type | URI | Serv->
---+--------------------------------------+--------------------------------------+-----------+-----------------+----------------+-----------+--------+-------------------------------------------------------------------------------+-------
1 | Google-Chrome | Google-Chrome | Nein | ---- | ---- | 99 | rpm-md | http://dl.google.com/linux/chrome/rpm/stable/x86_64 |
2 | download.opensuse.org-non-oss | Haupt-Repository (NON-OSS) | Ja | (r ) Ja | Ja | 99 | rpm-md | http://download.opensuse.org/tumbleweed/repo/non-oss/ |
3 | download.opensuse.org-oss | Haupt-Repository (OSS) | Ja | (r ) Ja | Ja | 99 | rpm-md | http://download.opensuse.org/tumbleweed/repo/oss/ |
4 | download.opensuse.org-tumbleweed | Hauptaktualisierungs-Repository | Ja | (r ) Ja | Ja | 99 | rpm-md | http://download.opensuse.org/update/tumbleweed/ |
5 | google-chrome | google-chrome | Ja | (r ) Ja | Ja | 99 | rpm-md | https://dl.google.com/linux/chrome/rpm/stable/x86_64 |
6 | https-download.opensuse.org-07ad1e64 | openSUSE:Tumbleweed | Ja | (r ) Ja | Ja | 99 | rpm-md | https://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/ |
7 | libdvdcss2 | libdvdcss2 | Ja | (r ) Ja | Ja | 99 | rpm-md | http://opensuse-guide.org/repo/openSUSE_Tumbleweed/ |
8 | openSUSE-20221113-0 | openSUSE-20221113-0 | Nein | ---- | ---- | 99 | rpm-md | hd:/?device=/dev/disk/by-id/usb-Intenso_Premium_Line_10152701000186-0:0-part2 |
9 | packman | packman | Ja | (r ) Ja | Ja | 90 | rpm-md | https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/ |
10 | repo-debug | openSUSE-Tumbleweed-Debug | Nein | ---- | ---- | 99 | NONE | http://download.opensuse.org/debug/tumbleweed/repo/oss/ |
11 | repo-source | openSUSE-Tumbleweed-Source | Nein | ---- | ---- | 99 | NONE | http://download.opensuse.org/source/tumbleweed/repo/oss/ |
12 | security | Security tools (openSUSE_Tumbleweed) | Ja | (r ) Ja | Ja | 99 | rpm-md | https://download.opensuse.org/repositories/security/openSUSE_Tumbleweed/ |
Geht doch ganz einfach per yast-software.
Anzeigen-> Repositories-> Haupt-Repository (NON-OSS)-> Systempakete auf dieses Repo umstellen
Wiederholen für OSS und Hauptaktualisierungsrepo…
Sieht nich seht tragisch aus. 
Zwei mal Google Chrome ist vielleicht etwas übertrieben. Ich würde #1 vortschaffen (dan bleibt die hhtps übrig).
Warum #6? Das ist eigentlich das einige Fragliche was ich habe.
Sonst wäre es am besten um bei irgendwelche Probleme, die du nur so nebenbei erwähnst, hier zu fragen.
Übrigens hast du recht:
zypper dup
ist das einzige Richtige (das --allow-vendor-change ist seit etwa zwei Jahre überfüssig da in Tumbleweed “default”, schadet aber nichts).
Und dann nachher doch wieder das Gleiche wechseln auf packman, sonst ist das völlig zu nichte gemacht.
Das Wissen habe ich jetzt vorausgesetzt, dass der Poster das Packman Repo deaktivieren muss danach.
Übrigens steht allowvendorchange auf false in der zypp.conf per default! Somit ist es weiterhin explizit erforderlich einen allowvendorchange zu machen, wenn man die configs nicht angepackt hat…
#1 hab ich jetzt rausgenommen. Ich erinnere mich da an einen gescheiterten Chrome-Installationsversuch, vermutlich war das ein Überbleibsel. Wie #6 reinkam, kann ich leider nicht beantworten, bewusst reingenommen hab ich es jedenfalls nicht. Explizit reingenommen habe ich nur google, libdvdcss2 und packman.
Setting ist solver.allowVendorChange = false
Ok, da habe ich tatsächlich ne Wissenslücke. Packman dann nur für das erste Update nach der Umstellung auf die System-Repos deaktivieren meint ihr, oder? Denn es sind durchaus noch Programme da, die nur in Packman verfügbar sind und die ich natürlich weiter aktuell halten will.
Das hattest du so im ersten Post nicht beschrieben. Dann dafst du Packman nicht deaktivieren.
Das heißt, du musst erst alle Pakete die in den openSUSE repos auch vorhanden sind zurückswitchen. Den solver musst du auf false lassen. Und du musst dir bewusst sein, dass du kein “dup --allow-vendor-change” mehr machen darfst, oder die Pakete werden alle wieder auf Packman zurückgeswitcht.
Normale “zypper dups” werden weiterhin alle Pakete die nur im Packman repo vorhanden sind aktuell halten.
Dein Vorgehen nur Pakete die auf Packman vorhanden sind zu installieren “kann” funktionieren, “muss” aber nicht. Das heißt so wie du es beschrieben hast, möchtest du selektiv Pakete von Packman installieren. Dazu musst du genau Bescheid über Abhängigkeiten wissen oder du handelst dir unter Umständen mehr Probleme ein als gewünscht…
Ok, so macht das Sinn. Also stelle ich in yast wie du es oben geschrieben hast die Systempakete auf NON-OSS, OSS und Hauptrepo und fahre dann ein zypper dup.
dup --allow-vendor-change hab ich nicht mehr vor zu benutzen. Kann ich eigentlich die Benachrichtigung, dass es neue Updates gibt, auch noch vendor-abhängig machen? Wenn ich es richtig sehe wird momentan nur aufgrund der Version benachrichtigt.
Wirf das raus, mach alle 3-4 Tage ein
zypper dup
das sollte reichen.
Hab jetzt einfach das Intervall auf nen Monat gesetzt, da bin ich manuell eh flinker.
Noch ne Anschlussfrage, weil mir gerade aufgefallen ist, dass die Ausgabe von sudo zypper search -s NetworkManager mir sowas liefert (Auszug der Liste):
S | Name | Type | Version | Arch | Repository
---+----------------------------------+-------+-------------+--------+-----------------------
| cockpit-networkmanager | Paket | 276.1-4.1 | noarch | Haupt-Repository (OSS)
| cockpit-networkmanager | Paket | 276.1-4.1 | noarch | openSUSE:Tumbleweed
| libKF5NetworkManagerQt-devel | Paket | 5.103.0-1.1 | x86_64 | Haupt-Repository (OSS)
| libKF5NetworkManagerQt-devel | Paket | 5.103.0-1.1 | x86_64 | openSUSE:Tumbleweed
| libKF5NetworkManagerQt-devel | Paket | 5.103.0-1.1 | i586 | Haupt-Repository (OSS)
| libKF5NetworkManagerQt-devel | Paket | 5.103.0-1.1 | i586 | openSUSE:Tumbleweed
i | libKF5NetworkManagerQt6 | Paket | 5.103.0-1.1 | x86_64 | Haupt-Repository (OSS)
i | libKF5NetworkManagerQt6 | Paket | 5.103.0-1.1 | x86_64 | openSUSE:Tumbleweed
v | libKF5NetworkManagerQt6 | Paket | 5.103.0-1.1 | i586 | Haupt-Repository (OSS)
v | libKF5NetworkManagerQt6 | Paket | 5.103.0-1.1 | i586 | openSUSE:Tumbleweed
i | libproxy1-networkmanager | Paket | 0.4.18-1.3 | x86_64 | Haupt-Repository (OSS)
i | libproxy1-networkmanager | Paket | 0.4.18-1.3 | x86_64 | openSUSE:Tumbleweed
v | libproxy1-networkmanager | Paket | 0.4.18-1.3 | i586 | Haupt-Repository (OSS)
v | libproxy1-networkmanager | Paket | 0.4.18-1.3 | i586 | openSUSE:Tumbleweed
| libproxy1-networkmanager-32bit | Paket | 0.4.18-1.3 | x86_64 | Haupt-Repository (OSS)
| libproxy1-networkmanager-32bit | Paket | 0.4.18-1.3 | x86_64 | openSUSE:Tumbleweed
i+ | NetworkManager | Paket | 1.42.2-1.1 | x86_64 | Haupt-Repository (OSS)
i+ | NetworkManager | Paket | 1.42.2-1.1 | x86_64 | openSUSE:Tumbleweed
v | NetworkManager | Paket | 1.42.2-1.1 | i586 | Haupt-Repository (OSS)
v | NetworkManager | Paket | 1.42.2-1.1 | i586 | openSUSE:Tumbleweed
openSUSE:Tumbleweed ist ja mein #6, wenn ich dem Link https://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/ folge, lande ich bei https://download.opensuse.org/tumbleweed/repo/oss/ , was ja #3 entspricht. Mal davon abgesehen, dass ich mir nicht erklären kann, wie das reinkam:
Das bedeutet, er listet meine Pakete doppelt, weil das gleiche Repo unter verschiedenen Namen/Links bekannt ist? Kann ich #6 dann einfach raus nehmen (und bei der Gelegenheit auch #8, was ein Überbleibsel der Erstinstallation sein dürfte)?
Darauf hatte dich hcvv schon am 2. März hingewiesen. Entferne #6, das ist ein 1-click-repo welches nur zu Problemem führt…
#8 ist dein originales Installationsmedium (USB-Stick) welchen du auch entfernen kannst. Deaktiviert ist er ja schon…
Er wollte wissen, warum das drin ist und das konnte ich nicht beantworten. Das ging dann auch mehr oder weniger unter. Dass es Probleme machen könnte, war für mich aus den Postings nicht hervorgegangen und die Sache mit den doppelten Einträgen ist mir erst heute aufgefallen.