[gelöst]k3b nur von Packman installieren, nicht KDE Backport

Alles rund um die Installation Eures Linuxsystems, sowie die Updatefunktionen des Systems und das Paketmanagement

Moderator: Moderatoren

Antworten
Benutzeravatar
WPosche
Member
Member
Beiträge: 200
Registriert: 21. Jan 2005, 19:41

[gelöst]k3b nur von Packman installieren, nicht KDE Backport

Beitrag von WPosche » 20. Okt 2006, 09:42

Habe neuerdings ein Problem. Weil bei den Packman Paketen ja neuerdings das k3b-mad Paket integriert ist, das aber in der offiziellen Variante nicht der Fall ist. Yast und der Zen Updater denken nämlich, dass die Version von KDE:/Backports neuer ist als die Packman Version und wollen diese dementsprechend immer installieren. Die KDE:/Backports Version enthält aber nicht k3b-mad. Da ich aber auch von mp3s Audio-CDs brennen möchte, will ich selbstverständlich die Packman Version behalten.

Wie kann man Yast jetzt beibringen, dass er bitte das Paket k3b einfach nicht mehr automatisch updaten soll? Im Zen-Updater nervt auch dieses Ausrufezeichen. Die Datei im Yast als Tabu-niemals installieren zu markieren, wie in diesem Thread beschrieben, hilft augenscheinlich ja nicht.
http://www.linux-club.de/viewtopic.php?t=69652

Gibt es da noch eine andere Möglichkeit??
Zuletzt geändert von WPosche am 22. Okt 2006, 21:41, insgesamt 1-mal geändert.
openSUSE 11.0
KDE 4.1

Werbung:
traffic
Guru
Guru
Beiträge: 2750
Registriert: 13. Feb 2005, 05:50

Beitrag von traffic » 20. Okt 2006, 20:43

Wenn die Versionsnummer des einen Pakets größer ist als die des anderen, dann ist das Paket mit der größeren Versionsnummer neuer als das andere -fertig.

Wenn Dich im Zen-Updater "dieses Ausrufezeichen nervt", dann verwende den Zen-Updater einfach nicht. Dieses Ausrufezeichen ist nun mal das Symbol, welches anzeigt, dass es Updates gibt.

Wenn Du aus einem bestimmen Katalog keine Updates erhalten möchtest, dann "unsubscribe" den Katalog. Entweder im Zen-Updater unter "Konfigurieren -> Catalogs" das Kreuzchen rausnehmen oder in der Befehlszeile:

Code: Alles auswählen

rug unsubscribe <Name des Katalogs>
openSUSE Factory - GNOME 2.32.1

Benutzeravatar
WPosche
Member
Member
Beiträge: 200
Registriert: 21. Jan 2005, 19:41

Beitrag von WPosche » 21. Okt 2006, 20:39

Naja, irgendwie finde ich schon, dass man dem Programm sagen können sollte, dass er ein Paket gar nicht aktualisieren soll, oder eben ein Paket immer nur von einer bestimmten Quelle installiert...
openSUSE 11.0
KDE 4.1

Grothesk
Ultimate Guru
Ultimate Guru
Beiträge: 14662
Registriert: 26. Okt 2003, 11:52
Wohnort: Köln

Beitrag von Grothesk » 21. Okt 2006, 21:00

smart kann das.
"Die Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen. Allerdings ist sie nicht OpenSource, d.h. du sollst sie nicht verändern oder in veränderter Form veröffentlichen."

rolle
Guru
Guru
Beiträge: 3721
Registriert: 4. Mai 2004, 21:50
Kontaktdaten:

Beitrag von rolle » 21. Okt 2006, 21:33

[klugscheiß] APT auch[/klugscheiß]
Horrido, Roland

Für meine Postings gilt außer bei Zitaten hier im Linux-Club die Creative Commons.

traffic
Guru
Guru
Beiträge: 2750
Registriert: 13. Feb 2005, 05:50

Beitrag von traffic » 22. Okt 2006, 18:45

Frage lesen!

Man kann übrigens auch auf miteinander in Konflikt stehende Repositories verzichten. Das muss man mit apt und smart zwar nicht, aber am grundsätzlichen Problem, dass Repositories, die dieselben Pakete bereitstellen, miteinander in Konflikt stehen, ändern auch apt und smart und Pinning und Locking nichts, da darf man den Paketen nämlich hinterherrennen, wenn in einem der Repos wieder Updates auftauchen, die man noch nicht gesperrt hat. ;)

Am fortgeschrittensten ist beim Locking übrigens weder apt noch smart, sondern yum. Bei yum kann man einfach sowas in die Konfigurationsdatei eines Repos schreiben:

Code: Alles auswählen

exclude=k3b
Zumindest smart kann das - Sperren von Paketen nach Repo - definitiv nicht, sondern nur nach Version. Da darf man sich dann aussuchen, ob man die installierte Version sperrt und nie irgendwelche Updates bekommt oder aber die nicht installierte Version sperrt und bei jedem weiteren Update hinterherrennen will. ;)

Noch viel besser bei yum:

Code: Alles auswählen

include=k3b
Auf die Art und Weise wäre k3b das einzige, das yum jemals aus dem Repo sieht. Wunderbar geeignet für Repos, in denen es massenhaft unerwünschte Updates und genau ein Zuckerstück gibt. ;)

Zenworks hat hier übrigens auch einiges zu bieten: Wenn man einen Katalog auf "unsubscribed" setzt, wie ich das vorgeschlagen hatte, dann werden aus diesem Katalog keine Updates mehr angezeigt, installieren kann man Pakete von dort aber immer noch. Das entspricht so mehr oder weniger der Einstellung "schlecht ist das Repo nicht, aber ich suche mir die Updates lieber aus".

Allerdings sind YaST und der zmd eigentlich gar nicht auf den Anwendungsfall zugeschnitten, dass man wirklich in Konflikt stehende Repos hat und auf der Paketebene die Rosinen rauspicken muss. Diese Tools sind eher auf die Zielgruppe zugeschnitten, wo die Regel "Ein Nicht-Distributions-Repo darf nie ein Update eines Distributions-Pakets anbieten" gilt und weniger für den Anwendungsfall "Ich tausche mal meinen kompletten KDE und das halbe Basissystem aus und mache dann einen Thread im Forum auf, um zu fragen, warum KDE meine Festplatten nicht mehr anzeigt".
openSUSE Factory - GNOME 2.32.1

Benutzeravatar
WPosche
Member
Member
Beiträge: 200
Registriert: 21. Jan 2005, 19:41

Beitrag von WPosche » 22. Okt 2006, 21:40

traffic hat geschrieben:Zenworks hat hier übrigens auch einiges zu bieten: Wenn man einen Katalog auf "unsubscribed" setzt, wie ich das vorgeschlagen hatte, dann werden aus diesem Katalog keine Updates mehr angezeigt, installieren kann man Pakete von dort aber immer noch. Das entspricht so mehr oder weniger der Einstellung "schlecht ist das Repo nicht, aber ich suche mir die Updates lieber aus".
Super. Auf die Idee bin ich noch gar nicht gekommen. Ich unsubscribe einfach, indem ich bei Konfiguration bei einem Katalog das Häkchen wegnehme, oder? Jetzt zeigt er zumindest kein Update mehr an und wie es aussieht kann ich relativ einfach auch wieder den Katalog auswählen.
traffic hat geschrieben:Allerdings sind YaST und der zmd eigentlich gar nicht auf den Anwendungsfall zugeschnitten, dass man wirklich in Konflikt stehende Repos hat und auf der Paketebene die Rosinen rauspicken muss. Diese Tools sind eher auf die Zielgruppe zugeschnitten, wo die Regel "Ein Nicht-Distributions-Repo darf nie ein Update eines Distributions-Pakets anbieten" gilt und weniger für den Anwendungsfall "Ich tausche mal meinen kompletten KDE und das halbe Basissystem aus und mache dann einen Thread im Forum auf, um zu fragen, warum KDE meine Festplatten nicht mehr anzeigt".
Hehe, sowas funktioniert aber trotzdem. Finde es einfach besser, für solche Dinge systemeigene Tools zu benutzen.
openSUSE 11.0
KDE 4.1

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast