Repos und Softwareverwaltung

Ich habe bereits in einem anderen Thread geschrieben dass ich aufgrund der neuen Skylake Architektur auf meinem Laptop den aktuellen Stable Kernel (zur Zeit: 4.5.2-2) installieren musste.
Da mir aber noch andere Softwarepakete wichtig sind, die u.a. auch Kernelmodule bereitstellen, musste ich noch weitere nicht-Standard Repos aus download.opensuse.org abonnieren.
Das führte jetzt leider dazu dass ich neben den Standard-Repos noch 6 weitere Repos abonniert habe.
Das wirft für mich die Frage auf wie ich mit diesen zusätzlichen Repos umgehe was zukünftige Paketinstallationen und Updates angeht.

  1. ist es gewährleistet dass ein Paket aus Repo A nicht mit einer aktuelleren Version aus Repo B aktualisiert wird ? Das wäre dann ja eigentlich gleichzeitig ein Anbieterwechsel.
    Schwierig abzusehen ist es auch wenn ein Paket aus Repo A eine Abhängigkeit hat die es nur in Repo B gibt und man später das Repo B kündigt.
  2. Gibt es ein Best Practice wie man mit diesen verschiedenen nicht-Standard Repos umgeht ?
    Ich habe nämlich vorerst mal alle non-Standard Repos deaktiviert. Könnte mir aber vorstellen dass ich denen auch einfach eine niedrigere Priorität einräume.

Eine andere Frage hätte ich noch zur Roadmap von LEAP selbst: wenn im Herbst 42.2 kommt, ist dann davon auszugehen dass es dann mit einem aktuellen Kernel kommt, z.B. 4.5 oder 4.6 und nicht erst 4.2 ?
Das würde dann nämlich heissen, dass auch Skylake Systeme richtig unterstützt würden und ich mir das eine oder andere zusätzliche Repo sparen könnte und ich gleichzeitig näher am Standard wäre. Das würde mein System auch weniger wartungsintensiv machen.

Ja.
Nur “zypper dup” macht das automatisch per default.

Schwierig abzusehen ist es auch wenn ein Paket aus Repo A eine Abhängigkeit hat die es nur in Repo B gibt und man später das Repo B kündigt.

Wenn man ein Repo “kündigt”, bleiben die Pakete daraus installiert.
Falls bei einem Update eine Abhängigkeit nicht erfüllbar ist, gibts einen Konflikt/eine Fehlermeldung.

  1. Gibt es ein Best Practice wie man mit diesen verschiedenen nicht-Standard Repos umgeht ?

Tja, ich denke dass das ziemlich davon abhängt, welche Repos du genau verwendest.
Kernel:stable beinhaltet sowieso nur den Kernel, also gibts da auch nicht besonders viel zu beachten.

Prinzipiell ist aber klar dass die Möglichkeit Probleme zu haben zunimmt, je mehr zusätzliche Repos eingebunden werden.
Getestet wird sowieso auch nur mit den Standardrepos…

Ich habe nämlich vorerst mal alle non-Standard Repos deaktiviert. Könnte mir aber vorstellen dass ich denen auch einfach eine niedrigere Priorität einräume.

Die Priorität kommt nur bei der Installation von neuen Paketen ins Spiel.
Ein neues Paket wird normalerweise von dem Repo mit der höchsten Priorität (= niedrigere Prioritätsnummer) genommen.
Falls ein Paket in mehreren Repos mit der gleichen Priorität enthalten ist, “gewinnt” das Paket mit der höchsten Versionsnummer.

Einem Repo eine niedrige Priorität zu geben sollte sicherstellen, dass Pakete daraus nur dann installiert werden wenn sie nirgendwo anders vorhanden sind.

Eine andere Frage hätte ich noch zur Roadmap von LEAP selbst: wenn im Herbst 42.2 kommt, ist dann davon auszugehen dass es dann mit einem aktuellen Kernel kommt, z.B. 4.5 oder 4.6 und nicht erst 4.2 ?

Ja.
4.2 macht absolut keinen Sinn und ist bereits “tot”, d.h. die Entwicklung ist eingestellt.

Es wäre komplett unsinnig jetzt extra für Leap 42.2 den 4.2er Kernel zu paketieren/maintainen (ohne Unterstützung der Upstream-Entwickler), vor allem da 4.4 schon vor Monaten erschienen und eine “longterm” Release ist, wie 4.1.

Persönlich glaube ich dass es entweder 4.4 oder 4.5 sein wird, soweit ich weiß ist das aber noch nicht entschieden.

Hi wolfi,

vielen Dank für die Antworten auf meine Fragen, die mir sehr weiterhelfen.

Wenn man mal auf kernel.org nachsieht,

https://kernel.org/

<Edit>
Zusätzliche Info zu den longterm Kerneln.

https://kernel.org/category/releases.html
</Edit>

dann könnte man vermuten, es wird am ehesten ein 4.4er werden (longterm).

4.5x wird wohl eher nicht ein longterm, 4.6 ist auch eher fraglich (auch wenn 3.10-3.18 immer im Abstand von 2 Releases longterm wurden) und der 4.7er kommt möglicherweise dann schon zu spät um ihn noch vor dem “Feature/Version Freeze” ausgiebig testen zu können, wobei auch da nicht sofort fest steht, ob dieser dann wieder ein longterm wird.

Das ist zwar “purer Spekulatius”, aber zumindest kein komplett unbegründeter.

AK