Jetzt kommt der Stein ins rollen - oder genauer, der Busch ins kullern! Ich habe den Vorschlag von David getestet und die Ergebnisse, entsprechen den Erwartungen - Danke David ! Worum ging es noch gleich? Es geht um die kontinuierliche Aktualisierung eines Tumbleweed-Systems. Wichtig ist hierbei der Begriff kontinuierlich. Nach dem bisherigen Verfahren, wird ein Tumbleweed-System einmalig mittels z.B. "zypper dup --from Tumbleweed" eingerichtet. Dabei werden alle auf dem System installierten Pakete, durch gleichnamige Pakete aus dem Tumbleweed-Repository aktualisiert - insofern sie dort vorhanden sind. Im nachfolgenden Betrieb des Systems, wird das Tumbleweed-Repository allerdings wie jedes andere Repository behandelt soll heißen, bei dem üblichen Aktualisierungsvorgang (z.B. via "Yast-Online-Update" oder "zypper up"), werden Pakete die im Tumbleweed-Repository eventuell neu hinzugekommen sind, nicht automatisch auf dem System installiert, da dies mit einem Anbieterwechsel verbunden wäre. An dieser Stelle habe ich mir gewünscht, dass das Tumbleweed-Repository ähnlich gewichtet wird und funktioniert wie das Update-Repository soll heißen, wenn dort neue Pakete hinzukommen, dann sollen sie bei einer typischen Aktualisierung ("Yast-Online-Update" oder "zypper up"), in jedem Fall auf meinem System installiert werden. Diese Funktionalität ist es, die ich mit der im Tumbleweed-Kontext propagierten Begrifflichkeit "Rolling Release" assoziiere. David hat nun einen Weg aufgezeigt, wie man diese Gleichberechtigung von update-Repository und Tumbleweed-Repository (genauer: den Anbietern) in einem System einrichten kann. Ich werde das hier noch einmal dokumentieren und dazu auch gleich ein paar von meinen Beobachtungen und Tests. Im Grunde geht es also darum, dass man dem System mitteilt, dass Aktualisierungen aus dem Tumbleweed-Repository auch dann durchgeführt werden, wenn diese Aktualisierung einen Anbieterwechsel bedeutet. Im Englischen wird diese Thematik mit "Vendor change update" betitelt und kann detailliert nachgelesen werden unter: http://en.opensuse.org/SDB:Vendor_change_update Für uns besonders interessant ist dort der Abschnitt "Allowing Vendor change in general" http://en.opensuse.org/SDB:Vendor_change_update#Allowing_Vendor_change_in_ge... Hier nun die konkrete Umsetzung in meinem Tumbleweed-System: Wir müssen eine Datei anlegen in der alle Anbieter aufgeführt sind für die wir einen automatischen Anbieterwechsel freigeben wollen. Die Position der Datei ist vorgegeben mit dem Verzeichnis /etc/zypp/vendors.d/ welches aber in der Regel nicht auf dem System vorhanden ist, deshalb: mkdir /etc/zypp/vendors.d Der Name der Datei kann frei vergeben werden. Ich wähle "Tumbleweed.conf". Wir erzeugen diese Datei und schreiben zwei Zeilen hinein: cat <<'EOF' >> /etc/zypp/vendors.d/Tumbleweed.conf [main] vendors = suse,opensuse,obs://build.opensuse.org/openSUSE:Tumbleweed EOF Eigentlich war es das schon und wir können mit dem update loslegen, dennoch einige Anmerkungen zum Syntax der "vendors-Zeile": Wir listen also drei Namen die aber nicht absolut sind, sondern als Ausdrücke behandelt werden. So kann ein hier aufgeführter Name, auf mehrere Anbieter zutreffen, siehe wie folgt: Groß/Kleinschreibung wird nicht unterschieden und verglichen wird der aufgeführte Name mit dem Anfang der Anbieternamen soll heißen der von uns aufgeführte Name "opensuse" trifft also auch die hypothetischen Anbieter "openSuSE-11.4" oder "opensuse-update". Die Namen der Anbieter, kann man ermitteln über z.B. "zypper if PAKETNAME". So liefert z.B. "zypper if kernel-desktop" ... Hersteller: obs://build.opensuse.org/openSUSE:Tumbleweed ... Während "zypper if glibc" folgendes aufzeigt: ... Hersteller: openSUSE ... BTW: Mich hat mal interessiert, wie viele unterschiedliche Anbietern sich da eigentlich auf meinem System tummeln und wie die alle heißen. Aus einem Befehl von David, habe ich mir dann folgendes zurecht gezimmert: rpm -qa --queryformat '%{vendor}\n' | sort -u Erstaunt nahm ich zur Kenntnis, dass es doch recht wenig sind. Außerdem stellte ich fest, dass ich keinen Anbieter habe, der mit "suse" beginnt, ich könnte mir das oben also sparen und die Vendor-Zeile reduzieren auf : vendors = opensuse,obs://build.opensuse.org/openSUSE:Tumbleweed Da die Gurus das aber in dem aufgeführten Dokument mit "suse" gemacht haben und ich ein Schisser bin, lasse ich das drin. Und wie ich so die bei mir vorhandenen Anbieternamen angucke und ich vermute, dass man die beim Paketbau wahrscheinlich selbst vergeben kann wird mir klar, dass ich mit dieser Lösung nicht wirklich das erreicht habe, was ich eigentlich wollte. Ich habe nämlich nur Namen von Anbietern frei gegeben und nicht Repositories. Ich verlasse mich also darauf, dass die Paketbauer die Vendor-Angabe gewissenhaft pflegen. Wenn also jemand im Packman-Repository ein Paket rein stellt, welches intern als Anbieter "openSuSE" oder aus Spaß "openSuSE-Fan" enthält, dann würde es installiert werden, auch wenn es aus einem "unerwünschten" Repository stammt ... Wie auch immer, hier noch ein paar Tests die stattfanden, nachdem ich die Datei Tumbleweed.conf angelegt habe. Dazu habe ich mir einzelne Pakete rausgesucht, die er vorher nicht mit einem allgemeinen "zypper up" updaten wollte und deshalb auflistete in der Sektion "Die folgenden Paketaktualisierungen werden NICHT installiert.". Ich habe dann einfach mal ein "zypper up" ausgeführt und geschaut, welche Pakete er nun installieren würde und welche nicht: Beispiel : libassuan0 Installiert : 2.0.1-4.1 openSUSE-11.4-11.4-0 Verfügbar : 2.0.2-4.1 Tumbleweed "zypper up" würde es jetzt updaten, so ist es gewünscht. Einem Anbieterwechsel nach Tumbleweed, wird nun zugestimmt. Beispiel : libldb0 Installiert : 0.9.7-2.6 @System Verfügbar : 0.9.7-2.17.1 repo-oss (openSUSE-11.4-Oss) "zypper up" würde es jetzt updaten, dieses Beispiel verstehe ich allerdings nicht. Was bedeutet die Anbieterangabe "@System"? Ich kann darüber keine Angabe in /etc/zypp/repos.d finden. Beispiel : nfs-client Installiert : 1.2.3-11.16.1 Aktualisierungen-für-openSUSE-11.4-11.4-0 Verfügbar : 1.2.3-27.1 Tumbleweed "zypper up" würde es jetzt updaten, so ist es gewünscht. Einem Anbieterwechsel nach Tumbleweed, wird nun zugestimmt. Beispiel : k3b Installiert : 2.0.2-6.9.1 repo-oss Verfügbar : 2.0.2-8.pm.13.3 packman.inode.at-suse "zypper up" würde es NICHT updaten, so soll es sein. Einem Anbieterwechsel wird NICHT zugestimmt. Das Konzept der klebrigen Anbieter (vendor stickiness concept), ist also nicht einfach komplett ausgehebelt und funktioniert somit noch. Beispiel : kernel-desktop Installiert : 3.0.0-38.1 @System Verfügbar : 3.0.1-40.1 Tumbleweed "zypper up" würde es NICHT updaten. Hier verstehe ich 2 Dinge nicht. Zum Einen wieder die Geschichte mit "@System" und zum Anderen, warum würde er es nicht updaten? Liegt das daran, dass es sich um einen Kernel-Update handelt? Ein explizites "zypper up kernel-desktop", hat jedenfalls funktioniert. Nochmals Dank an David ! -- Herzliche Grüße Tao -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org