-
Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.
[gelöst] kupdateapplet und Fremdrepos
- Ersteller tlu
- Erstellt am
OP
tlu
Member
lOtz1009 schrieb:Naja wie soll ich mich bei etwas auskennen, was ich nicht benutze
Hehe, stimmt
Ich versuche jetzt mal den Stand der Dinge zusammen zu fassen:
- Standardmäßig überprüft das Updater Applet nur das Update Repo auf Updates.
- Das ist offenbar auch dann der Fall, wenn "Verfügbare Aktualisierungen anzeigen, wenn das Dienstprogramm sie anbietet (Expertenmodus)" gewählt ist, sofern man als Dienstprogramm PackageKit benutzt. D.h. keine Einbeziehung von Fremdrepos.
- Diese sind erst einbezogen, wenn das Dienstprogramm auf Zypp umgestellt wird. Das Verhalten müsste dann mit zypper up bzw. "Paket -> Alle Pakete -> Aktualisieren, falls neuere Version vorliegt" in der Yast Softwareverwaltung übereinstimmen. D.h. es werden alle Repos aktualisiert, aber ohne Repowechsel.
- Der Repowechsel findet erst statt bei "Paket -> Alle Pakete -> Unbedingt aktualisieren", was zypper dup entspricht.
Habe ich das so richtig verstanden? Wenn ja, bedeutet das, dass die erwähnten KDE-Pakete deshalb nicht über das Applet upgedatet wurden, weil dieses standardmäßig PackageKit benutzt.
OP
tlu
Member
lOtz1009 schrieb:Das würde ich jetzt mal so unterstreichen
Hach - danke. Ich bin anscheinend doch nicht so blöd, wie ich dachte.
Aber das bedeutet doch, dass jeder, der Fremdrepos benutzt (und wer tut das nicht?) und logischerweise Wert darauf legt, dass diese auch aktualisiert werden, und gleichzeitig das Updater Applet verwendet, auf jeden Fall kupdateapplet-zypp installieren sollte, damit Applet, Yast und zypper ein konsistentes Verhalten zeigen. Insofern muss ich sagen, dass die Standardkonfiguration doch ziemlich zur Verwirrung der Benutzer (zumindest Anfänger) beiträgt. Das könnte man besser machen ...
Könnte man vielleicht. Aber andererseits sollten Anfänger eigentlich erstmal nur die Basisrepos benutzen - zumindestens so lange, bis sie wissen, was sie tun. :roll:tlu schrieb:
Bei dir ist das wohl etwas anderes - du bist ja kein Anfänger, sondern nur ein Suse-Anfänger.
OP
tlu
Member
Rainer Juhser schrieb:
Stimmt - aber dem würde ein konsistentes Verhalten von Applet, Yast und zypper ja nicht entgegen stehen.
Bei dir ist das wohl etwas anderes - du bist ja kein Anfänger, sondern nur ein Suse-Anfänger.
Daher wahrscheinlich mein nerviges Insistieren
Und deshalb gleich noch eine letzte Frage, weil dieses Thema für mich noch nicht geklärt ist, nämlich die Frage nach den Prioritäten: Wenn das so richtig ist, wie wir das in diesem Thread herausgearbeitet haben, relativiert sich doch die Bedeutung der Prios ganz erheblich. Wenn ich z.B. die KDE-Repos neu hinzufüge, komme ich an die neuen Pakete nur über zyper dup oder "Paket -> Alle Pakete -> Unbedingt aktualisieren" heran. Diese werden künftig dann über zypper up oder "Paket -> Alle Pakete -> Aktualisieren, falls neuere Version vorliegt" oder das Updater Applet mit dem Zypp-Modul (nicht dagegen mit dem PackageKit-Modul) aktualisiert, da ja dann kein Repowechsel mehr stattfindet. Und zwar auch dann, wenn ich die Prio auf standardmäßig 99 gelassen hätte. Insofern geht doch die immer wieder zu lesende Empfehlung, die Prios z.B. der KDE- oder Packman-Repos auf 50 oder so etwas zu setzen, an der Realität vorbei - oder?
Frage also: Was bringt das Setzen der Prios?
EDIT: Ich kann übrigens bestätigen, dass mir das Updater Applet heute nach der Umstellung auf zypp zum ersten Mal nicht nur Fehlerkorrekturen (waren heute keine dabei), siondern auch Aktualisierungen präsentiert hat. So wollte ich's haben - schön
Repowechsel != Anbieterwechsel
Wenn du z.B. mehrere Repos aus dem Buildservice eingebunden hast, die das selbe Paket in verschiedenen Versionen anbietet, spielt das Ganze schon eine Rolle.
Es sei denn, der gesamte Buildservice wird nicht mehr als einziger Anbieter gesehen, sondern pro obs-Projekt unterteilt, zu der Policy habe ich aber bisher noch nichts gelesen.
Wenn du z.B. mehrere Repos aus dem Buildservice eingebunden hast, die das selbe Paket in verschiedenen Versionen anbietet, spielt das Ganze schon eine Rolle.
Es sei denn, der gesamte Buildservice wird nicht mehr als einziger Anbieter gesehen, sondern pro obs-Projekt unterteilt, zu der Policy habe ich aber bisher noch nichts gelesen.
Alle 3 Repos aus dem BuildService. Bei diesen 3 ist die Wahrscheinlichkeit, dass Pakete doppelt vorhanden sind, eher gering. Sollte dies aber der Fall sein, so greift die Priorität durchaus, da ein Wechsel des Repos in diesem Fall kein Anbieterwechsel ist und somit kein "dup" zum Repowechsel benötigt würde.
So war es jedenfalls bisher, da der gesamte Buildservice (egal welches Repo daraus) als ein einzieger "Anbieter" angesehen wurde.
Ob sich seit der Namensgebung (von "openSUSE - BuildService" nach "obs://obs.opensuse.org/$PROJEKT" diese Annahme geändert hat, habe ich nirgends belegt gefunden.
Repo (Installationsquelle) ist also nicht direkt als Anbieter zu sehen.
Verwirrung komplett?