Hallo Helga, hallo zusammen, Am Montag, 19. Juni 2017, 21:36:02 CEST schrieb Helga Fischer:
Du hast mal wieder echt gute Hintergrundinfos.
Das Thema "zypper up" vs. "zypper dup" und "--no-allow-vendor-change" wird auf opensuse-factory oft genug diskutiert ;-)
Am Montag 19 Juni 2017 schrieb Christian Boltz:
Am Montag, 19. Juni 2017, 00:57:11 CEST schrieb Helga Fischer: ...
Hmmm... zypper dup funktioniert - behaupte ich. Über YaST auch. (Letztens hat's YaST auch endlich geschafft, den Schlüssel für das KDE3-Repo endlich mal endgültig das Vertrauen auszusprechen; zypper hat jedes Mal wieder nachgefragt).
Warum sollte man bei Tumbleweed keinen vendor-change zulassen? (Kann mich gar nicht erinnern, dass das auftritt; was aber nichts heißen will).
Wenn man den vendor-change erlaubt, kommt es gern mal zu lustigem hin- und-her-Springen eines Pakets z. B. zwischen openSUSE und Packman - bei gleicher Versionsnummer entscheidet dann der Rebuild-Counter das Wettrennen ;-)
Aha. Kann ich das nicht durch den YaST-Mechanismus des 'Wechsel von x-Repo zu y-Repo' verhindern?
Die Option klingt nicht schlecht, aber ich habe ehrlich gesagt YaST schon seit Jahren nicht mehr fürs Paketmanagement benutzt - zypper gefällt mir besser ;-) Ich würde sogar behaupten, dass ich öfter eine Mail auf der yast-devel ML schreibe [1] als ich YaST starte ;-)
Zusätzlich dem y-Repo noch eine höhere Priorität zuweisen und fortan ist nur noch y-Repo am Drücker?
Stimmt, mit den Prioritäten kann man da auch noch spielen ;-) wobei der Begriff "höhere Priorität" immer verwirrend ist, weil kleinere Zahlen bevorzugt werden. (Merkhilfe: "Rangfolge"/"Platzierung" statt "Priorität") Ich habe z. B. home:cboltz mit Priorität 100 eingebunden, damit die Pakete aus Tumbleweed bevorzugt werden. home:cboltz kommt also nur dran, wenn ein Paket nicht in Tumbleweed ist oder wenn ich zypper ausdrücklich dazu zwinge ;-) (was ich z. B. bei den AppArmor-Paketen mache - und da verhindert --no-allow-vendor-change den Wechsel zurück zu den Tumbleweed-Paketen)
Obwohl... vendor-changes habe ich hin- und wieder auch, aber so aus dem Gedächtnis heraus weiß ich nicht, wann sie auftreten und erst recht nicht, ob sie gestresst haben.
AFAIK wurden dank ausgelaufener Patente einige Pakete von Packman direkt in Tumbleweed integriert (und dann bei Packman gelöscht) - es gibt also auch Fälle, in denen ein vendor-change sein muss. In diesen Fällen bekommst Du dann bei "zypper dup --no-allow-vendor-change" eine Konflikt- Info und kannst den vendor-change für dieses Paket freigeben. Ein vendor-change ist nicht per Definition "böse" - trotzdem ist in den meisten Fällen --no-allow-vendor-change die bessere Wahl.
Mit --no-vendor-change werden immer die Pakete aus dem gleichen Repo genommen - Packman-Pakete werden also nur mit Packman-Paketen aktualisiert.
Daher will man in der Regel --no-vendor-change benutzen ;-)
OK. Alles nicht so einfach mit so vielen Paketen...
Solange die Pakete alle aus einem Repo sind, ist es einfach. Interessant[tm] wird es nur mit zunehmender Zahl an Repos ;-) Um das Ganze 100% korrekt zu erklären: mehrere Repos können den selben vendor haben. Innerhalb dieser Gruppe erfolgt dann der Wechsel trotz --no-allow-vendor-change ohne Nachfrage. Das bekannteste Beispiel dafür sind die Hauptrepos (oss und non-oss) sowie das Update-Repo, die alle "openSUSE" als vendor haben. Es wäre ja auch nervig, wenn man bei jedem Sicherheits-Update auch noch einen vendor change genehmigen müsste ;-) Ach so: rpm -qi $paket zeigt u. a. "Vendor" Gruß Christian Boltz [1] schwerpunktmäßig, wenn es ums YaST AppArmor-Modul bzw. dessen Rewrite geht -- Aber da du unter den Hardcore Freaks noch in der "extrem-hardcoring" Ecke zu finden bist (*), wird die Kluft zwischen deinen Anforderung und dem was der Markt hergibt noch grösser als bei den meisten anderen. (*)wer sonst hier in der Liste liest sendmail.cf files als Abendlektüre! [Andreas Kyek in suse-linux über David Haller] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org