Repositoryverwaltung ohne Verschlimmbesserung aufräumen

Deutsch (German) Installation/Administration
1

Wenn etwas plötzlich nicht mehr läuft, obwohl es vorher keine Probleme gab, kann es an einer ungünstigen Kombination von Paketdepots und deren Prioritäten liegen. Daher erscheint es mir sinnvoll, spätestens in dem Moment in dem Bereich etwas aufzuräumen.

Was gibt es dabei in der Praxis zu beachten? Wie geht ihr damit um? Welche Befehle verwendet ihr? Welche Tips habt ihr? Vor allem: welche Fehler muss man unbedingt vermeiden?

Zum Beispiel sollte man wohl nicht ohne Weiteres ein Repository löschen, oder?
Dabei frage ich mich schon auch, was man tut, wenn es einfach nicht mehr zur Verfügung steht.
Ist es vielleicht eigentlich doch kein besonders Problem, wenn man eins löscht?

Daher interessieren mich die einzelnen Schritte genauer. Wie geht ihr vor und was beachtet ihr dabei?
(Und worum braucht man sich keinen Kopf zu machen.)

Sagen wir mal, ich hätte das Paketdepot https://download.opensuse.org/repositories/home:redwil:15.4/15.4/, in dem sowohl im Namen als auch im Alias ‘redwil’ vorkommt, und bei dem ich annehme, es nicht zu brauchen.

Die Ausgabe von
zypper se -si | grep redwil
bzw. zypper search --details --installed-only | grep redwil
ist leer.

Ist damit sichergestellt, dass das Repository keinerlei Einfluss auf mein Gesamtgefüge hat und dass ich es somit getrost löschen kann?

2

Aus dem anderen Beitrag:

zypper se -sir REPOPNAME|NUMMER|URL

REPOPNAME|NUMMER|URL muss natürlich ersetzt werden:
zypper search -s -i -r 1
bedeutet dann:
Zeige mir alle installierten (-i) Pakete in einer etwas ausführlichen (-s) Liste, die aus dem Repo mit NUMMER# 1 (-r 1)installiert sind.

Und diese 3 Optionen kann man dann so zusammenfassen
zypper se -sir 1

Siehe zypper help oder zypper BEFEHL --help

PS:
Deine Repoliste wäre schon hilfreich:
zypper lr -d

3

Ich mache das einfach über Yast, dort Software installieren und löschen, dann in die Suche gehen und Paketnamen eingeben. Du kannst das auch über Zypper machen. Aber Yast ist der einfachere Weg. Und wenn Du eine Übersicht Deiner Repositories (endlich) mal posten wolltest, gehst Du unter Software installieren und löschen in den Karteireiter > Konfiguration und postest hier die Liste Deiner Repositories (bitte in “code” - entweder den Text zwischen [/code] … [code] setzen oder stattdessen auf das Symbol in der Leiste unter “Reply” </> klicken).

4

Dann sieht man aber auch Pakete, die scheinbar aus zwei Repos installiert wurden. Welches Repo kann man dann gefahrlos löschen?

duncan:~ #  zypper se -sir 16
Loading repository data...
Reading installed packages...

S | Name                  | Type    | Version           | Arch   | Repository
--+-----------------------+---------+-------------------+--------+------------------
i | gio-branding-openSUSE | package | 42.1-lp156.9.2.2  | noarch | update-oss (15.6)
i | openSUSE-2024-153     | patch   | 1                 | noarch | update-oss (15.6)
i | openSUSE-2024-154     | patch   | 1                 | noarch | update-oss (15.6)
i | yast2-theme           | package | 4.6.0-lp156.2.2.1 | noarch | update-oss (15.6)
i | yast2-theme-breeze    | package | 4.6.0-lp156.2.2.1 | noarch | update-oss (15.6)
duncan:~ #  zypper se -sir 33
Loading repository data...
Reading installed packages...

S | Name                  | Type    | Version           | Arch   | Repository
--+-----------------------+---------+-------------------+--------+--------------------------------
i | gio-branding-openSUSE | package | 42.1-lp156.9.2.2  | noarch | Hauptaktualisierungs-Repository
i | openSUSE-2024-153     | patch   | 1                 | noarch | Hauptaktualisierungs-Repository
i | openSUSE-2024-154     | patch   | 1                 | noarch | Hauptaktualisierungs-Repository
i | yast2-theme           | package | 4.6.0-lp156.2.2.1 | noarch | Hauptaktualisierungs-Repository
i | yast2-theme-breeze    | package | 4.6.0-lp156.2.2.1 | noarch | Hauptaktualisierungs-Repository
5

Die sind nicht aus zwei Repos installiert, sondern zwei Repos bieten die gleiche Version an, weil beide Repos auf das gleiche Ziel zeigen. Ohne das du deine Repoliste zeigst (welche keinerlei private Daten enthält oder irgendwelche Rückschlüsse zulässt) ist das Ganze hier relativ fruchtlos…

6

Ich bin nicht der OP. Würde ich meine Repoliste angeben, dann wäre das verwirrend … der OP wurde ja darum gebeten. Ich wollte darauf hinweisen, dass der angegebene Befehl nicht unbedingt das Repo angibt, aus dem installiert wurde. Der OP wollte ja wissen, wie man herausbekommt welche Repos man löschen kann und in dem von mir angegebenen Fall geht es aus dem bisher gesagten noch nicht hervor.

7

@waspo:
Schau dir mal die URL von Repo 16 und 33 an.
Sollten gleich sein.
Beide zeigen auf das Update (Hauptaktualisierungs) Repo.

Eines von beiden kannst du löschen.

Das hat @hui auch schon gesagt:

8

Die sind verschieden.
Nicht mal die IP-Adressen stimmen überein.

http://cdn.opensuse.org/update/leap/15.6/oss
http://download.opensuse.org/update/leap/15.6/oss

Mir ist schon klar, dass beide inhaltlich gleich sind oder sein sollen oder gewöhnlich sind. Aber wird das Paket nicht als “orphaned” eingestuft wenn man sein Ursprungs-Repo rausnimmt? Oder kommt es nur auf den kompletten Namen des RPM an und die Quelle wird nirgendwo nachgehalten?

9

Die beiden URLs SIND gleich. cdn.opensuse.org und download.opensuse.org sind lediglich unterschiedliche Loadbalancer für das EXAKT gleiche Repo /update/leap/15.6/oss

Und damit ist dein Paket nicht orphaned, wenn du eine der beiden URLs entfernst. Beide Loadbalancer zeigen auf das gleiche Repo.

Wenn du wissen willst was ein Loadbalancer ist und macht, da gab es die letzten Tage hier einen Thread im englischen Forum…

10

Ich weiß was das ist und ich habe auch keine Probleme die Repos aufzuräumen. Aber ich finde die Frage des OP sehr vernünftig und wichtig:

Woran sieht man als User welche Repos überflüssig sind?

Es reicht nicht mit zypper se -sir xxx nachzusehen, ob sie unbenutzt sind. Dabei werden überflüssige Repos als im Gebrauch befindlich dargestellt.

Es reicht nicht, die URLs zu vergleichen. Dabei sehen gleiche Repos verschieden aus.

Natürlich kann man hier im Forum fragen und erfährt es dann. Aber es sollte doch eine Möglichkeit geben, die überflüssigen Einträge selbst zu ermitteln.

11

Da kommt es dann darauf an, was der User als überflüssig ansieht.

Eine grundsätzliche Antwort gibt es nicht, nur Empfehlungen.

Hier mal die Erklärung (auf deutsch) über die Download-Infrastruktur von openSUSE:
Download-Infrastruktur

12

Wenn du ein Repo löscht, werden nicht die daraus installierten Pakete deinstalliert.
Sonst könntest du ja auch keine rpms herunterladen und installieren…
Die werden nur als oprhaned/verwaist angezeigt.

Wenn das Paket in 2 deiner eingebundenen Repos vorhanden ist (gleicher Anbieter, gleiche Version/Release), und du eines dieser Repos löscht, ist das Paket immer noch im anderen Repo vorhanden.
Und wird nicht als orphaned/verwaist angezeigt.

13

Danke!
(und noch was wegen der 10 Zeichen)

14

Okay, das habe ich gemacht. Mit dem Kniff der Reponummer (inkl. Beispiel) war es besonders praktisch.

Bei mehreren war das Ergebnis leer.
Mehrere Repos davon habe ich dann gelöscht.
Leider musste ich aber feststellen, dass Letzteres bei mir wohl doch ein Fehler war, denn
zypper pa --orphaned zeigte dann, dass mit der Aktion mehrere Pakete verwaist waren.

Somit muss ich nun doch auf die harte Tour lernen … Zum Glück ist dabei dank kleiner Sicherheitsmaßnahmen wohl nichts komplett verloren oder kaputt gegangen.
Und der weitere Austausch mit waspo kommt mir da sehr gelegen; danke auch dafür.

Ein paar Dinge sind mir nach alledem immer noch unklar. Insbesondere der oben beschriebene Fehler, der ja meine ursprüngliche Frage betrifft.

Hierzu erst einmal ein paar Infos zum aktuellen Stand:

Meine Repoliste ist nun halbwegs aufgeräumt, zumindest so, dass sie hier jetzt als Grundlage für die Analyse taugt. Glaubt mir, ihr wolltet sie im Zustand davor nicht sehen :wink:
Im Ernst: Ich wollte erstmal die Repos entfernen, die irrelevant sind (eben die, von denen eh nichts da ist) und nur unnötig verwirren. Nun habe ich diejenigen, deren Löschung zu verwaisten Paketen geführt haben, wieder drin.

$ zypper pa --orphaned
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Keine Pakete gefunden.
$ zypper verify
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Die Abhängigkeiten aller installierten Pakete sind berücksichtigt.

$ zypper lr -dP
#  | Alias                                                                                         | Name      | Enabled | GPG Check | Refresh | Priority | Type   | URI                                                                               | Service
---+-----------------------------------------------------------------------------------------------+-----------+---------+-----------+---------+----------+--------+-----------------------------------------------------------------------------------+--------
 1 | http:ftp.halifax.rwth-aachen.depackmansuseopenSUSE_Leap_15.5                                  | Packman   | Ja      | (r ) Ja   | Nein    |   70     | rpm-md | http://ftp.halifax.rwth-aachen.de/packman/suse/openSUSE_Leap_15.5/                |
 2 | https:download.opensuse.orgrepositoriesgraphics15.5_fuer_pdfsam                               | https:/-> | Ja      | (r ) Ja   | Nein    |   75     | rpm-md | https://download.opensuse.org/repositories/graphics/15.5                          |
12 | repo-backports-update                                                                         | Update -> | Ja      | (r ) Ja   | Nein    |   80     | rpm-md | http://download.opensuse.org/update/leap/15.5/backports/                          |
18 | repo-openh264                                                                                 | Open H.-> | Ja      | (r ) Ja   | Nein    |   80     | rpm-md | http://codecs.opensuse.org/openh264/openSUSE_Leap/                                |
21 | repo-sle-update                                                                               | Update -> | Ja      | (r ) Ja   | Nein    |   80     | rpm-md | http://download.opensuse.org/update/leap/15.5/sle/                                |
23 | repo-update                                                                                   | Main Up-> | Ja      | (r ) Ja   | Nein    |   80     | rpm-md | http://download.opensuse.org/update/leap/15.5/oss/                                |
24 | repo-update-non-oss                                                                           | Update -> | Ja      | (r ) Ja   | Nein    |   80     | rpm-md | http://download.opensuse.org/update/leap/15.5/non-oss/                            |
17 | repo-non-oss                                                                                  | Non-OSS-> | Ja      | (r ) Ja   | Nein    |   81     | rpm-md | http://download.opensuse.org/distribution/leap/15.5/repo/non-oss/                 |
19 | repo-oss                                                                                      | Main Re-> | Ja      | (r ) Ja   | Nein    |   81     | rpm-md | http://download.opensuse.org/distribution/leap/15.5/repo/oss/                     |
10 | openSUSE-Leap-15.5-1                                                                          | openSUS-> | Nein    | ----      | ----    |   82     | rpm-md | hd:/?device=/dev/disk/by-id/usb-General_USB_Flash_Disk_...                        |
 3 | https:download.opensuse.orgrepositorieshome:Evoka015.5_fuer_freeplane                         | https:/-> | Ja      | (r ) Ja   | Nein    |   85     | rpm-md | https://download.opensuse.org/repositories/home:Evoka0/15.5                       |
 4 | https:download.opensuse.orgrepositorieshome:ahmedmoselhi2:branches:video15.5_fuer_libx265-199 | https:/-> | Ja      | (r ) Ja   | Nein    |   85     | rpm-md | https://download.opensuse.org/repositories/home:ahmedmoselhi2:branches:video/15.5 |
 5 | https:download.opensuse.orgrepositorieshome:edogawa15.5_fuer_pdftk-gui                        | https:/-> | Ja      | (r ) Ja   | Nein    |   85     | rpm-md | https://download.opensuse.org/repositories/home:edogawa/15.5                      |
 6 | https:download.opensuse.orgrepositorieshome:fusionfuture:joplin15.5                           | https:/-> | Ja      | (r ) Ja   | Nein    |   85     | rpm-md | https://download.opensuse.org/repositories/home:fusionfuture:joplin/15.5/         |
 7 | https:download.opensuse.orgrepositorieshome:uwemock15.5_fuer_jes                              | https:/-> | Ja      | (r ) Ja   | Nein    |   85     | rpm-md | https://download.opensuse.org/repositories/home:uwemock/15.5                      |
 8 | https:download.opensuse.orgrepositoriesnetwork:im:signal15.5network:im:signal.repo            | https:/-> | Ja      | (r ) Ja   | Nein    |   85     | rpm-md | https://download.opensuse.org/repositories/network:im:signal/15.5/                |
11 | repo-backports-debug-update                                                                   | Update -> | Nein    | ----      | ----    |   90     | NONE   | http://download.opensuse.org/update/leap/15.5/backports_debug/                    |
13 | repo-debug
[ Rest irrelevant und deaktiviert ...]

So. Nehmen wir als Beispiel nun Repo 6 für Joplin.

**zypper search -s -i -r 6**
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
**Keine passenden Objekte gefunden.**

Da ich in dem Fall aus der URL weiß, dass ich es für das Paket joplin-desktop habe, kann ich in Yast nachsehen, welche Version von welchem Repo installiert ist.
Und ja, dort steht “2.12.19-lp155.1.1 vom Anbieter obs://build.opensuse.org/home:fusionfuture (installiert)”
Und es steht eine neue Version zur Verfügung: ‘2.14.22-lp155.1.1’.

Woher kommt der Widerspruch?

Bei Signal war mir das Gleiche passiert. Da wurde ich natürlich stutzig und habe natürlich aufgehört, zu löschen. (Für manche Repos, die genauso aussahen, zu spät, siehe oben.)

Repo home:fusionfuture habe ich zu keinem Zeitpunkt gelöscht, auch wenn die Ausgabe hier leer war.
Bei Signal habe ich das Repo auch nicht gelöscht, aber das Paket inzwischen aktualisiert.
Seitdem lautet die Ausgabe bei gleichem Befehl:

$ zypper search -s -i -r 8
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name              | Type  | Version          | Arch   | Repository
---+-------------------+-------+------------------+--------+-----------------------------------------------------------------------------------------
i+ | signal-desktop    | Paket | 7.14.0-lp155.1.1 | x86_64 | https://download.opensuse.org/repositories/network:im:signal/15.5/network:im:signal.repo
i  | signal-libringrtc | Paket | 2.44.0-lp155.1.1 | x86_64 | https://download.opensuse.org/repositories/network:im:signal/15.5/network:im:signal.repo

:thinking: Es sieht also so aus, dass zypper se -sir REPOPNAME|NUMMER|URL genau genommen anzeigt, welche Pakete in der exakt gleichen Version sowohl bei mir als auch im Repo vorhanden sind. Richtig?

Wenn die Anzeige leer ist, darf ich daraus jedoch offensichtlich nicht zweifelsfrei schließen, dass dieses Repo dennoch die Quelle für ein installierten Paket sein kann.

Normalerweise ist da ja kein Unterschied, wenn die Pakete der Repos alle aktuell sind… Das erscheint stimmig.

Dennoch wüsste ich gern, ob es einen Weg gibt, in dem man die Abhängigkeit zuverlässiger feststellen kann.

Nach dem Löschen kann man es mit zypper pa --orphaned feststellen. Für davor wäre eine Variante davon im Konjunktiv hilfreich, etwa in der Art: Welche Pakete würden verwaisen, wenn dieses Repo gelöscht würde. :wink:
Kennt ihr so etwas?

15

Alle von Dir gezeigten Repositories sind auf nicht automatisch aktualisieren gesetzt (Refresh => Nein). Gibt es dafür einen Grund, wenn ja, welchen?

16

Ja, das ist richtig. Aber keine Sorge: vor jede Paketaktualisierung kommt ein zypper refresh, bei denen die aktivierten Repos aktualisiert werden. Der Effekt ist damit der gleiche.

17

Dann lass uns die Frage eingrenzen: Woran sieht man als User, welche Repos insofern überflüssig sind, als sie nirgendwo Quelle von irgendeinem installierten Paket sind und somit durch ihre Löschung keine Gefahr entsteht, dass eine relevante Aktualisierung des installierten Systems fehlen würde.

Nicht ganz das Gleiche, aber vom Zweck her eigentlich so, wie wir es von der Paketverwaltung gewohnt sind: Wollen wir da ein Paket (egal, wie alt oder neu es ist) löschen, werden wir gewarnt, wenn dadurch Abhängigkeiten futsch gehen würden.

18

Wenn die Ausgabe leer ist, ist kein Paket aus dem angefragten Repo installiert.
Deswegen das -i in dem Befehl.
Und nein, es ist keine Quelle für ein installiertes Paket.

PS:
Eines kann ich sagen:

  1. Weniger Repos erhalten oft die Systemstabilität
  2. von /home Repos rate ich ab, selbst von meinem rate ich ab.
    Ich weiß was ich in meinem Repo so mache.
19

Wenn du das -i und das -r aus dem Befehl weglässt, dann wird nach allen verfügbaren (egal ob installiert oder nicht) Paketen gesucht, die den Suchstring im Namen haben.
Die erste Spalte der Ausgabe gibt dann mit einem i an, das welchem Repo das Paket installiert ist.

zypper se -s r8168-kmp-default
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name                        | Type  | Version                                   | Arch   | Repository
---+-----------------------------+-------+-------------------------------------------+--------+---------------
i+ | r8168-kmp-default           | Paket | 8.053.00_k5.14.21_150500.53-lp155.66.2    | x86_64 | (Systempakete)
i+ | r8168-kmp-default           | Paket | 8.053.00_k6.4.0_150600.21-lp156.66.3      | x86_64 | Sauerland-OSS
v  | r8168-kmp-default           | Paket | 8.053.00_k6.4.0_150600.23.7-150600.1.pm.2 | x86_64 | Packman_Aachen
   | r8168-kmp-default-debuginfo | Paket | 8.053.00_k6.4.0_150600.23.7-150600.1.pm.2 | x86_64 | Packman_Aachen

Installiert sind 2 Pakete aus meine /home Repo, wie man sieht.

Hier sieht man beim ersten Paket auch in der letzten Spalte “Systempaket”, das bedeutet:
Dies Paket ist installiert aber in keinem der eingebundenen Repos vorhanden.
Das ist passiert, weil ich das Repo gelöscht bzw. beim Upgrade von Leap 15.5 auf Leap 15.6 die URL auf 15.6 geändert habe.
Es bleibt installiert.

Hintergrund:
Dies System ist von Leap 15.5 auf Leap 15.6 upgegraded.
Dabei musste ich auch meine “speziellen” Hardwaretreiber in Leap 15.6 installieren.
Um einen Fallback Kernel zu haben, musste ich natürlich auch die Treiber für den Leap 15.5 Kernel behalten. Sonst hätte ich mit dem Kernel z.B. kein Internet.

Es ist noch Kernel 5.14 aus Leap 15.5 installiert, der wird aber kürzlich gelöscht, da alles zu meiner Zufriedenheit läuft.

zypper se -si kernel-default r8168-kmp | grep -i '5.14'
i+ | kernel-default          | Paket | 5.14.21-150500.53.2                    | x86_64 | (Systempakete)
i+ | kernel-default-devel    | Paket | 5.14.21-150500.53.2                    | x86_64 | (Systempakete)
i+ | kernel-default-extra    | Paket | 5.14.21-150500.53.2                    | x86_64 | (Systempakete)
i+ | kernel-default-optional | Paket | 5.14.21-150500.53.2                    | x86_64 | (Systempakete)
i+ | r8168-kmp-default       | Paket | 8.053.00_k5.14.21_150500.53-lp155.66.2 | x86_64 | (Systempakete)
20

Dass du diese Antwort so allgemeingültig formulierst, überrascht mich nun doch. Denn wie ich oben beschrieben habe, ist es bei mir anders.

Meinst du, es könnte an etwas liegen, das bei Home-Repos anders ist, als bei denen von openSUSE?
Das beschriebene Beispiel von Repo 8 ist doch von openSUSE oder nicht?
https://download.opensuse.org/repositories/network:im:signal/…

Bei mir war Signal aus dem Repo installiert und dennoch die Ausgabe von $ zypper search -s -i -r 8 leer. (Mit der Option -i.)
Gleichzeitig wurde es bei zypper se -si --verbose | grep signal angezeigt als “distribution” angezeigt.
Es hat sich genau so verhalten, wie jetzt der Fall von Joplin, wo das Repo refresht ist und das Paket noch nicht aktualisiert ist.

Mag ja sein, dass ich irgendetwas falsch interpretiere und völlig auf dem Schlauch stehe, daher hier für euch die aktuellen Ausgaben zu Joplin:

$ zypper search -s -i -r 6
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Keine passenden Objekte gefunden.

Siehe Zeile: Keine passenden Objekte gefunden.

$ zypper se -si --verbose | grep joplin
i+ | joplin-desktop                             | Paket   | 2.12.19-lp155.1.1                                   | x86_64 | (Systempakete)
    name: joplin-desktop
    provides: application(@joplinapp-desktop.desktop)
    provides: mimehandler(x-scheme-handler/joplin)
    provides: joplin-desktop = 2.12.19-lp155.1.1
    provides: joplin-desktop(x86-64) = 2.12.19-lp155.1.1
    url: https://joplinapp.org/
    distribution: home:fusionfuture:joplin / 15.5
    filelist: /usr/bin/joplin-desktop
    filelist: /usr/share/applications/@joplinapp-desktop.desktop
    filelist: /usr/share/icons/hicolor/128x128/apps/joplin.png
   [... weitere icons ...]
    filelist: /usr/share/icons/hicolor/96x96/apps/joplin.png

Siehe insbesondere Zeile distribution: home:fusionfuture:joplin / 15.5.

Wie erklärst du dir das?
Wo siehst du die Ursache dieses Unterschiedes?
Ist ‘home:fusionfuture:joplin / 15.5’ deines Erachtens Quelle vom installierten Joplin-Paket oder nicht? Wenn nicht, woher kommt es dann?