Richtig?
Richtig. Aber ganz so einfach ist das auch wieder nicht. Priorisierung der Repos und Repolisten sind eine Wissenschaft für sich. Es gibt Leute, die meinen, je mehr Repos sie haben desto besser. Tödlicher Fehler. Aber das würde jetzt hier zu weit führen.
Das reicht mir so. Danke!
Jetzt muss ich das noch mit Plasma-Login-Manager ausprobieren, um das Thema abzuschließen. 
Die Installation eines noch nicht installierten!!!! Paketes verläuft so:
zuerst schaut zypper anhand der Priorität, ob es ein Paket in einem Repo mit höherer (niedrige Zahl) Priorität gibt, wenn ja, wird installiert, wenn nein schaut zypper anhand der Version und nimmt dann das Paket mit der höchsten Versionsnummer.
Da Packman und OSS oft dieselbe Version beherbergen, aber anders gebaut werden, sollte man eigentlich die Packman Version bevorzugen daher -p 40.
Kann aber unter Tumbleweed zu Problemen führen, bekannt ist hierfür z.B. Mesa.
Kann aber unter Tumbleweed zu Problemen führen, bekannt ist hierfür z.B. Mesa.
Und genau darum geht es mir ja. Heißt, ich sollte in diesem Fall keine Prio 40 nutzen?
Und genau darum geht es mir ja. Heißt, ich sollte in diesem Fall keine Prio 40 nutzen?
Das Repo ist komplett auf Priorität 40 gesetzt, andernfalls würde der dup auf das Repo nicht unbedingt funktionieren.......
Bei Mesa würde ich erst einmal abwarten und schauen,
Das Problem ist:
Packman baut gegen factory und da kann es Probleme geben, Pakete bauen nur teilweise usw.
Werden dann zwar irgendwann geändert, sodaß sie bauen, das kann aber dauern.
Factory ist das devel Projekt von Tumbleweed.
Das bedeutet die Pakete kommen erst nach Tumbleweed wenn sie alle freigegeben sind.......
Im schlimmsten Fall bekomme ich beim Update Fehlermeldungen bezüglich Mesa Paketen. Ein paar Tage später sollten diese dann aber gelöst sein und mir die Updates installiert werden.
Wenn das so ist, dann kommt mir das aus Fedora bekannt vor.
Double Commander
Es kann so einfach sein ... nimm das Appimage
Mir fällt gerade auf, dass das AppImage von den openSUSE-Servern geladen wird.
https://download.opensuse.org/repositories/home:/Alexx2000/AppImage/doublecmd-qt-latest-x86_64.AppImageMir fällt gerade auf, dass das AppImage von den openSUSE-Servern geladen wird.
Ja, steht ja auf der Downloadseite auch in Klammern dahinter 
Jetzt habe ich das auch registriert ... 
Wenn du es unbedingt ausprobieren möchtest
Nun wollte ich es wissen. Nachdem ich die beiden Pakete aus dem /home-Repo installiert hatte, stoppte ich den sddm-Dienst. Beim Starten des plasmalogin-Dienstes erscheint ein Fehler. 
$ sudo zypper in plasma6-login-manager plasma6-login-manager-kcm
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Paketabhängigkeiten werden aufgelöst...
Die folgenden 2 NEUEN Pakete werden installiert:
plasma6-login-manager plasma6-login-manager-kcm
2 neue Pakete zu installieren.
Paketgröße zum Herunterladen: 575,7 KiB
Änderung der Installationsgröße des Pakets:
| 2,5 MiB erforderlich für Pakete, die installiert werden sollen
2,5 MiB | - 0 B freigegeben von Paketen, die entfernt werden sollen
Backend: classic_rpmtrans
Fortfahren? [j/n/v/...? zeigt alle Optionen] (j):
Vorladen: plasma6-login-manager-6.7.0-21.1.x86_64.rpm [fertig]
Vorladen: plasma6-login-manager-kcm-6.7.0-21.1.x86_64.rpm [fertig]
Vorladen abgeschlossen. [Erfolg (15,6 KiB/s) ] .....................................................................[fertig]
Abrufen: plasma6-login-manager-kcm-6.7.0-21.1.x86_64 (Plasma-Login-Manager) (1/2), 149,3 KiB
Abrufen: plasma6-login-manager-6.7.0-21.1.x86_64 (Plasma-Login-Manager) (2/2), 426,5 KiB
Überprüfung auf Dateikonflikte läuft: ..............................................................................[fertig]
(1/2) Installieren: plasma6-login-manager-kcm-6.7.0-21.1.x86_64 ....................................................[fertig]
/usr/bin/systemd-sysusers --replace=/usr/lib/sysusers.d/plasmalogin.conf -
Creating group 'plasmalogin' with GID 461.
Creating user 'plasmalogin' (PLASMALOGIN Greeter Account) with UID 461 and GID 461.
(2/2) Installieren: plasma6-login-manager-6.7.0-21.1.x86_64 ........................................................[fertig]
Ausgabe des Skripts %transfiletriggerin(systemd-260.2-1.1.x86_64):
/usr/lib/tmpfiles.d/sddm.conf:14: Duplicate line for path "/tmp/xauth_*", ignoring.
Nach-Transaktions-Skripte werden ausgeführt ........................................................................[fertig]
denalb@PROMETHEUS-openSUSE:~> sudo systemctl disable sddm
denalb@PROMETHEUS-openSUSE:~> sudo systemctl enable plasmalogin
Failed to enable unit: File '/etc/systemd/system/display-manager.service' already exists and is a symlink to /usr/lib/systemd/system/display-manager-legacy.serviceDiesen Fehler hatte ich gestern Abend auch. Da konnte ich ihn mit dem Parameter --force verhindern. Aber dann funktionierte der Plasma-Login-Manager nicht.
Was würdest du nun tun, Sauerland . 