[gelöst] Wie Programme immer auf neuesten Stand?

Move · 15 Juli 2012

Hallo,
ich habe openSUSE 12.1 und KDE4.
Ich wollte meine Programme immer auf den neuesten Stand halten.
Installierte mit Apper die Updates, er meldete danach keine neuen Updates, dann führte ich per Yast
eine Onlineaktualisierung durch, er zeigte mir keine Aktualisierungen an.
Dann gab ich noch in der Konsole zypper update ein, der meldete auch keine Aktualisierungen.

Dann ging ich in Yast Software installieren und suchte Amarok und siehe da, es gab eine neue Version
von Amarok die mir nirgends angezeigt wurde.
Werden die Programmupdates selbst ausgeschlossen von den Updates?
Wie kann ich prüfen ob es neue Versionen meiner Programme gibt, denn immer über Yast
manuell nach allen Programmen suchen ist ein bisschen viel Arbeit.

tomm.fa · 15 Juli 2012

Du suchst wahrscheinlich nach Upgrades und nicht Updates. Was geben denn:

Code:

zypper lr -d

Code:

zypper lu

Code:

zypper se -s amaraok

Code:

zypper -vv dup -D

aus?

Move · 15 Juli 2012

Code:

ove@linux-elje:~> zypper lr -d
# | Alias                                       | Name                                        | Aktiviert | Aktualisieren | Priorität | Typ    | URI                                                                                        | Dienst
--+---------------------------------------------+---------------------------------------------+-----------+---------------+-----------+--------+--------------------------------------------------------------------------------------------+-------
1 | Aktualisierungen-für-openSUSE-12.1-12.1-1.4 | Aktualisierungen für openSUSE 12.1 12.1-1.4 | Ja        | Ja            |   99      | rpm-md | http://download.opensuse.org/update/12.1/                                                  |       
2 | download.opensuse.org-mozilla               | openSUSE BuildService - Mozilla             | Ja        | Ja            |   99      | rpm-md | http://download.opensuse.org/repositories/mozilla/openSUSE_12.1/                           |       
3 | openSUSE-12.1-12.1-1.4                      | openSUSE-12.1-12.1-1.4                      | Nein      | Nein          |   99      | yast2  | cd:///?devices=/dev/disk/by-id/ata-PHILIPS_DVD+_-RW_SDVD8820_CN0GH7666886568N0A36,/dev/sr0 |       
4 | packman.inode.at-suse                       | Packman Repository                          | Ja        | Ja            |   99      | rpm-md | http://packman.inode.at/suse/12.1/                                                         |       
5 | repo-debug                                  | openSUSE-12.1-Debug                         | Ja        | Ja            |   99      | yast2  | http://download.opensuse.org/debug/distribution/12.1/repo/oss/                             |       
6 | repo-debug-update                           | openSUSE-12.1-Update-Debug                  | Ja        | Ja            |   99      | rpm-md | http://download.opensuse.org/debug/update/12.1/                                            |       
7 | repo-non-oss                                | openSUSE-12.1-Non-Oss                       | Ja        | Ja            |   99      | yast2  | http://download.opensuse.org/distribution/12.1/repo/non-oss/                               |       
8 | repo-oss                                    | openSUSE-12.1-Oss                           | Ja        | Ja            |   99      | yast2  | http://download.opensuse.org/distribution/12.1/repo/oss/                                   |       
9 | repo-source                                 | openSUSE-12.1-Source                        | Ja        | Ja            |   99      | yast2  | http://download.opensuse.org/source/distribution/12.1/repo/oss/                            |

Code:

Move@linux-elje:~> zypper lu
Daten des Repositories laden ...
Installierte Pakete lesen ...
Keine Aktualisierungen gefunden.

Code:

Move@linux-elje:~> zypper se -s amaraok
Daten des Repositories laden ...
Installierte Pakete lesen ...
Keine Pakete gefunden.

Amarok habe ich mittlerweile schon über Yast aktualisiert.
Mit dem letzten Befehl kommt ganz schön viel Zeug 14 neue Pakete und 150 erneut installieren.
Soviel ich mitbekommen habe macht er einen Architekturwandel, von i586 zu i686, welchen Sinn hat das?

Ich kenne mich mit zypper noch nicht gut aus, kannte für aktualisieren nur den Befehl "zypper update"
Lautet der Befehl für upgrades anders?

Herz-von-Hessen · 15 Juli 2012

Hallo Move,

Move schrieb:
Dann ging ich in Yast Software installieren und suchte Amarok und siehe da, es gab eine neue Version
von Amarok die mir nirgends angezeigt wurde.

Die Repositories sind mit einer bestimmten Priorität versehen, das regelt aus welcher Paketquelle etwas installiert/aktualisiert werden soll oder nicht.
Beispiel:
Repositorie-Liste:

Code:

Repositorie  |  Priorität   |   Programm    |   verfügbare Version
--------------------------------------------------------------------
oss          |  99          |   firefox     |   12 (vorinstalliert)
update       |  99          |   firefox     |   13
non-oss      |  99          |   firefox     |   16
packman      |  99          |   firefox     |   13
apps         |  99          |   firefox     |   13

Dann würde bei einem zypper up der Firefox bei Version 12 bleiben weil das Paket (firefox) daraus ist und keines der anderen Repos eine höhere Priorität hat.
(niedrigere Zahl bedeutet höhere Priorität)
Wolltest Du dann aber doch unbedingt die Version 13 installiert haben, wäre ein Repositorie-übergreifendes Update per zypper dup eine Möglichkeit.
Diese würde zwar den Firefox dann aus dem update-Repositorie auf die Version 13 updaten, aber auch alle anderen Pakete bei denen es neuere Versionen gibt würden
einen Anbieterwechsel machen, dies kann dann oft zu nicht lösbaren Abhängigkeiten führen.

Deswegen ist es wichtig das Du Deine Prioritäten geschickt verteilt hast (Alles auf 99 wie hier, ist Unsinn), dies kann man mit dem bereits genannten:

Code:

zypper lr -up | cut -d"|" -f1,2,6,7[code]
(Der Parameter [b]-up[/b] sorgt dafür das die URL und die Priorität mit angezeigt werden; das [b]cut -d"|" -f1,2,6,7[/b] filtert die für Deinen Fall nötigen Spalten heraus.)

Wie kann ich prüfen ob es neue Versionen meiner Programme gibt, denn immer über Yast [/quote]
Immer ein [b]zypper dup[/b] zu mache wäre, je nach Verteilung der Priorität, schädlich.
Es gibt aber auch die Option
[code]zypper in http://ur/zumm/repository/MozillaFirefox-13.0.1-1.1.x86_64

Damit würde explizit diese Version aus dem angegebenen Repository installiert werden.
Bei einem darauf folgenden zypper up würde dieses Paket so lange bestehen bis es in "oss" eine neuere Version gibt.
Aber bei einem darauf folgenden zypper dup würde dieses Paket durch das aus "non-oss" aktualisiert werden (also Version 16) und alles was noch irgendwo neuer zu finden ist.

lieben Gruß aus Hessen

Move · 29 Juli 2012

Ein bisschen kompliziert, aber im großen und ganzen verstanden.

Wie muss ich also meine Prioritäten vergeben dass ich immer die neueste Version aller Programme bekomme?

Die Versionen sind immer unterschiedlich in den Paketquellen, oder?
Somit werden immer einige Programme benachteiligt wenn ich das richtig verstanden habe

Herz-von-Hessen · 30 Juli 2012

Hallo Move,

Move schrieb:
Ein bisschen kompliziert, aber im großen und ganzen verstanden.

Komplizierter als Debians Repositoryverwaltung, ja, vor allem weil es für openSUSE mehr Repos gibt.
Man muss aber nicht jedes Repository in der Liste haben nur weil man daraus ein Paket installiert hat.
Das VideoLan-Repo braucht man nur genau einmal um die "böse" libdv...s zu installiern, dann kann am die Paketquelle entfernen weil es von diesem Paket keinen Update-Kandidaten gibt, die Bibliothek ist quasi schon perfekt weil sie genau das tut was man von Ihr erwartet.
Den VLC-Player würde ich mir, wie die Multimediasachen überhaupt, nur von Packman beziehen.

Move schrieb:
Wie muss ich also meine Prioritäten vergeben dass ich immer die neueste Version aller Programme bekomme?

Wenn Du immer von allem die jeweils aktuellste Version zeitnah haben möchtest, dann geht das eigentlich nur über ein händisches installieren.
Bei einem zypper dup kann es auch vorkommen das bestimmte Pakete kein Upgrade sondern ein Downgrade benötigen um bestimmte Abhängigkeiten erfüllen zu können oder weil die Priorität es nicht anders zulässt. (Danke an Lutz),
Dieser Weg ist aber absolut nicht zu empfehlen für ein Produktivsystem mit dem man sicher arbeiten möchte.
Es ist nunmal so das man sich für eine bestimmte Linie, resp. einen Anbieter entscheidet weil dieser dafür sorgt dass das was er anbietet so gut als möglich miteinander arbeitet.
Packman z.B. empfehle ich uneingeschränkt für den "normalen" Desktopnutzer der surft, chattet, Filme & Musik konsumiert und spielt.
Wer dagegen spezielle Programme benötigt wie z.B. Netzwerktools oder Php-Kram, der wird auch eher einen darauf spezialisierten Anbieter in seine Repoliste aufnehmen.

Move schrieb:
Die Versionen sind immer unterschiedlich in den Paketquellen, oder?
Somit werden immer einige Programme benachteiligt wenn ich das richtig verstanden habe

Nein die Verionsnummern sind nicht immer unterschiedlich und wenn dann spielt sich das überhaupt nur hinter dem ersten Punkt ab und nicht bei den Major Nummern.

Versuche erstmal zu verstehen warum es nicht möglich (und erst recht nicht notwendig) ist immer von allem die aktuellste Version zu haben.
Wenn ein großes Entwicklerteam wie das um die Mozilla-Produkte etwas entwickelt, dann kann man von dort auch damit rechnen das es in einem schnellen Zyklus zu Aktualisierungen kommt.
Diesen Aktualisierungsinterwall kann man von einem Ein-Personen-Projekt nicht unbedingt erwarten.
So kommt von Mozilla der offizielle Firefox 17 heraus, aber der "kleine" Entwickler eines Addons kommt eventuell erst vier Tage später mit einer daran angepassten Version auf den Markt weil er nur am Wochenende Zeit hat zum programmieren.
Sein Addon wiederum hat dann als Abhängigkeit noch eine oder mehrere Bibliotheken in einer bestimmten Version, die Entwickler der jeweiligen Bibliotheken sind aber aus unterschiedlichen Ländern und Zeitzonen und haben Ihre Anpassungen/Erweiterungen aber jeder an einem anderen Tag fertig.

Anders als es bei Microsoft der Fall ist, gibt es in der Linux Welt keinen Projektleiter der über die jeweiligen Entwicklungsstände aller zu Linux gehörenden Programme, Programmteile und Bibliotheken den Überblick hat.
Wie denn auch, wenn jeder Programmierer frei ist.

Immer das jeweils neuste zu haben ist gar nicht machbar, denn es kommt immer darauf an wie Du selbst "Das Neuste" definierst.
Deswegen gibt es meist mehrere Stufen einer Entwicklung bis hin zum fertigen Produkt.

Die Entstehung eines Programms in groben Zügen beispielhaft dargestellt.
Am Anfang steht die Idee, die nur im Kopf des Programmierers ist
Er überlegt sich wie er seine Idee umsetzen kann (es gibt ja mehr als einen Weg zum Ziel)
Er entscheidet sich für Variante A und setzt diese um.
Daraus entsteht eine Entwicklerversion noch ganz ohne Versionsnummer.
Der Programmierer schaut sich sein Werk an und wägt ab ob es das ist was er wollte, ist dem so, dann
Es wird eine Alpha Version veröffentlicht, die ist für die ganz probier-freudigen die auch Programmieren und vor allem debuggen können.
Diese Menschen bringen Ihre Verbesserungsvorschläge mit ein und der Programmierer von Variante A kann diese benutzen, muss es aber nicht.
Die folgenden Veröffentlichungen sind immer noch Alpha und es gibt keine feste Regel ab wann man es dann Beta-Version nennen muss.
Irgendwann ist dem Programmierer dann der Entwicklungsstand so genehm das er sagt "Die Versionen 0.0.1 bis 0.9.9 waren alle Alpha und die Version 1.0.1 wird als Beta-Version bezeichnet.
Auch so eine Beta-Phase hat keinen Festen Zeitrahmen ab wann es keine mehr ist.
Es ist nun endlich soweit das auch der Beta-Status irgendwann beendet wird und so kommt es zu einer ersten richtigen Release.
Die Version 1.5.0 ist in meinem Beispiel diese erste "richtige Version" und findet bei den Benutzern richtig viel Anklang so das dieses Projekt sich rasend schnell verbreitet und sich wachsender Beliebtheit erfreut.
Jetzt ist der Moment wo sich weitere Mitstreiter zum Projekt von Programmierer Variante A gesellen und sich daran beteiligen möchten.
Die weiteren Mitstreiter übernehmen Teilaufgaben des Projektes und entwickeln genau nur diese weiter.
Da es aber mehrere sind die wiederum unterschiedlich Zeit haben kommt es zu unterschiedlichen Entwicklungszuständen der Einzelteile, das gefällt dem Programmierer Variante A nicht und er ernennt sich (oder einen anderen) zum Maintainer, also einen der über die Entwicklungszustände aller beteiligten informiert ist und bestimmt welches Teil, und wann ins große Ganze übernommen wird.
Ist dann der Maintainer mit seiner Arbeit fertig, so bietet er das Projekt den Paketschnürnern (z.B. Packman) an und diese nehmen es auf oder eben nicht.
Da nun aber der Maintainer sein Programm weit verbreiten will bietet er es auch noch anderen Repositorys an die entscheiden ob sie das Projekt unterstützen oder nicht.
Die Paketschnürner der unterschiedlichen Repository-Anbieter (Packman, XYZ, ZZZ) haben wieder mehrere Mitarbeiter (meist freie) und dementsprechend viel Manpower um Variante A mehr oder weniger schnell aufnehmen zu können.
So kommt es dann dazu das bei Packman die Version 1.5.5 bereits am 01.10.2012 bereit steht aber bei Paketschnürner XYZ erst am 13.10.2012 und bei Paketschnürner ZZZ sogar erst am 15.10.2012.
Aus diesem Grund gibt es auch bei den Repositorys unterschiedliche Zweige → Playground,Testing, Tumbleweed, Stable...oder wie auch immer genannt.
Du als End-Anweder entscheidest selbst bei welchem Repositorys Du der Meinung bist das die Ihre Arbeit zu Deiner Zufriedenheit machen und setzt dann dieses auf eine höhere Priorität (niedrigere Nummer) um zukünftig immer das neuste von Repository-Anbieter (Packman, XYZ, ZZZ) zu bekommen. Es kann auch mal passieren das XYZ schneller als Packman oder ZZZ scheller als XYZ ist weil bei denen gerade mehr Zeit ist um Projekt Variante A einzupflegen während bei den Konkurrenz-Repos gerade Urlaubszeit ist und dadurch weniger Personal mitarbeiten kann.

Das ist jetzt die Sache hier nur aus einer Sicht geschildert;
was aber ist mit den Projekten von denen Variante A abhängig ist, auch da wird ja unabhängig voneinander weitergearbeitet, es kommt eine neue Kernelversion, diverse aktualisierte Bibliotheken ect. pp.
Du kannst bestimmte jede Woche einen neueren Kernel compilieren und wärst damit gezwungen viele Deiner installierten Programme (X-Server, Grafikkartentreiber, Fenstermanager, Desktop, Anwenderprogramme, Tools ect.) ebenfalls neu zu compilieren damit diese miteinander harmonieren.
All diese Arbeit nimmt Dir das Team deines Repositorys ab, so das Du nichts machen musst als ein bequemes zypper -v up einzugeben.
Ich denke das die allermeisten "normalen" Anwender keine 20 Repos dauerhaft benötigen sondern mit 10 schon mehr als alles abgedeckt haben.

Ich hoffe ich konnte Dir den Zusammenhang deutlich machen.

Um Dir nun eine bestimmte Priorisierung zu raten wäre es wichtig zu sehen welche Pakete Du woher beziehst und zu wissen welche Pakte Du im speziellen immer "so aktuell wie möglich" haben möchtest.
Ich habe hier z.B. den Firefox 17 am laufen obwohl der noch gar nicht als normale Release veröffentlicht wurde, kann aber auch meine normale 14er Version benutzen.

Ich würde die Priorität Deiner Repositorys wie folgt anordnen:

Code:

# | Name                                        | Priorität | URI
--+---------------------------------------------+---------------------------------------------+-----------+---------------+-----------+--------+----------------------------------------------------------$
1 | Aktualisierungen für openSUSE 12.1 12.1-1.4 |   30      | http://download.opensuse.org/update/12.1/
2 | openSUSE BuildService - Mozilla             |   30      | http://download.opensuse.org/repositories/mozilla/openSUSE_12.1/
3 | openSUSE-12.1-12.1-1.4                      |   99      | cd:///?devices=/dev/disk/by-id/ata-PHILIPS_DVD+_-RW_SDVD8820_CN0GH7666886568N0A36,/dev/sr0
4 | Packman Repository                          |   20      | http://packman.inode.at/suse/12.1/
5 | openSUSE-12.1-Debug                         |   99      | http://download.opensuse.org/debug/distribution/12.1/repo/oss/
6 | openSUSE-12.1-Update-Debug                  |   99      | http://download.opensuse.org/debug/update/12.1/
7 | openSUSE-12.1-Non-Oss                       |   99      | http://download.opensuse.org/distribution/12.1/repo/non-oss/
8 | openSUSE-12.1-Oss                           |   99      | http://download.opensuse.org/distribution/12.1/repo/oss/
9 | openSUSE-12.1-Source                        |   99      | http://download.opensuse.org/source/distribution/12.1/repo/oss/

Das kann man so bewerkstelligen:
Die Priorität von Repository 4 (Packman) auf 20 setzen:

Code:

zypper mr -p 20 4

Die Priorität von Repository 1 (Aktualisierungen für openSUSE 12.1 12.1-1.4) und Repository 2 (openSUSE BuildService - Mozilla) auf 30 setzen:

Code:

zypper mr -p 30 1 2

Die Debug- und Source-Repos entfernen, die braucht man als Entwickler, nicht aber als Anwender:

Code:

zypper rr 5 6 9

Danach noch ein beherztes:

Code:

zypper -v dup --dry-run

Das ist ein Trockenlauf um zu sehen was getan würde. Ist man damit einverstanden kann man den Upgrade-Vorgang starten:

Code:

zypper -v dup

Danach kommt mit Sicherheit eine Meldung das einige Prozesse die aktualisiert wurden noch laufen und man diese ansehen kann, braucht man aber nicht, es reicht einfach einen Neustart zu machen

Code:

reboot

oder

Code:

shutdown -r now

lieben Gruß aus Hessen

lOtz1009 · 30 Juli 2012

zypper -v dup
, welches dann die Prioritäten komplett außer Acht lässt und die aktuellste Version daher bezieht wo diese gerade zu finden ist.

Das ist Quatsch. dup hält sich an die Prioritäten.

halo44 · 30 Juli 2012

Wenn Ihr mir erlaubt, würde ich mich gerne hier mal mit einer Frage einklinken.

Ich habe meine Repositories auch mit Prioritäten versehen und verstehe nicht, warum sich YaST bei mir z.B. den Mozilla Firefox aus dem Repo mit der Priorität 50 und nicht aus dem mit der Priorität 45 installiert :

Code:

3 | Mozilla_Repository-12.1            | Mozilla Repository 12.1            | Ja        | Ja            |   45      | http://download.opensuse.org/repositories/mozilla/openSUSE_12.1/                                                                                                                                                                   
 1 | Aktualisierungen_für_openSUSE_12.1 | Aktualisierungen für openSUSE 12.1 | Ja        | Ja            |   50      | http://download.opensuse.org/update/12.1/

Warum kann diese Situation so entstehen?

Mein Firefox hat die Version 14.0.1-2.33.1, wie ihn die "Aktualisierungen für openSUSE 12.1" anbieten und nicht die 14.0.1-2.1 aus dem "Mozilla_Repository-12.1".

Benötige ich das letztere Repo überhaupt? Ich weiß leider nicht mehr, wann und warum ich es eingefügt habe, denn ich muß es vermutlich ja gewesen sein

ps:

Gruss H.

josef-wien · 30 Juli 2012

Update-Repo = openSUSE
Mozilla-Repo = build service

Solange Du YaST keinen Hersteller-Wechsel erlaubst, wird ein solcher nicht erfolgen. Abgesehen davon ist 14.0.1-2.33.1 formal eine höhere Version als 14.0.1-2.1.

P. S. Seit Mozilla die Versionsnummer alle 6 Wochen hochschraubt, ist mir der Sinn des Mozilla-Repo auch nicht mehr klar.

Feuervogel · 30 Juli 2012

Hallo halo44,

hast Du vorher mal ein zypper dup gemacht? Da werden ja auch Paketwechsel vorgeschlagen.

Hast Du dem zugestimmt, dann nimmt er beim nächsten "normalen" Update (zypper up) die Version, die aus dem entsprechenden Repository kommt.

Gruß
Feuervogel

Heinz-Peter · 30 Juli 2012

Hier ist alles gut erklärt: http://de.opensuse.org/SDB:Zypper_benutzen und http://de.opensuse.org/SDB:YaST_Repositorys_hinzuf%C3%BCgen
Gruß

halo44 · 30 Juli 2012

josef-wien schrieb:
... Solange Du YaST keinen Hersteller-Wechsel erlaubst, wird ein solcher nicht erfolgen ...

Wenn ich unter YaST die Online-Aktualisierung wähle und unter Optionen nachsehe, ist dort der Herstellerwechsel erlaubt.

Feuervogel schrieb:
... hast Du vorher mal ein zypper dup gemacht? Da werden ja auch Paketwechsel vorgeschlagen ...

Mit zypper arbeite ich eigentlich nur, wenn ich ein bestimmtes Paket installieren, oder überprüfen will, ob es installiert ist.

Den zypper dup habe ich nur einmal gemacht, als ich den Wechsel von der Suse 11.4 zur 12.1 gemacht habe (nach dem Howto von IOtz1009). Ob ich damals irgendwelche Herstellerwechsel vollzogen habe, weiß ich leider nicht mehr.

Die Patches für meine Installation mache ich über YaST / Online-Aktualisierung.

Gruss H.

Herz-von-Hessen · 30 Juli 2012

Hallo Lutz,

lOtz1009 schrieb:
zypper -v dup
, welches dann die Prioritäten komplett außer Acht lässt und die aktuellste Version daher bezieht wo diese gerade zu finden ist.

Zum Vergrößern anklicken....

Das ist Quatsch. dup hält sich an die Prioritäten.

dup erlaubt den Herstellerwechsel; ergo kann zypper eine neuere Version doch aus einem anderen Repo holen!?
Das man dennoch gefragt wird ob man sicher ist das tun zu wollen ändert doch nichts daran das alle Verfügbaren Versionen einer Software bei einem

Code:

zypper se -s paketname

angeboten werden.
Wenn man dann die force-Option zieht wird ohne Nachfrage installiert was woher am neusten ist.
Wo ist da bitte mein Denkfehler?

lieben Gruß aus Hessen

Heinz-Peter · 30 Juli 2012

Vielleicht bringt der alte Beitrag etwas Licht in die Sache? http://www.linux-club.de/viewtopic.php?f=62&t=111898
Sehr interessant ist hier der Beitrag von tomm.fa => http://www.linux-club.de/viewtopic.php?p=697642#p697642
Gruß

lOtz1009 · 30 Juli 2012

Herz-von-Hessen schrieb:
dup erlaubt den Herstellerwechsel; ergo kann zypper eine neuere Version doch aus einem anderen Repo holen!?

Paket Version 1.0 in Repo A (Prio 50)
Paket Version 1.1 in Repo B (Prio 99)

Bei einem zypper dup müsste hier 1.0 installiert werden, da die Prio der Repos geringer ist (obwohl das Paket in Repo B eine höhere Versionsnummer hat).

halo44 · 31 Juli 2012

Ich muß nochmal nachhaken :

Wenn mir auch die Argumentation von josef-wien hinsichtlich der formal höheren Version einleuchtet, wie erkläre ich mir aber folgende Beispiele :

Code:

S | Name | Typ   | Version     | Arch | Repository             
--+------+-------+-------------+------+------------------------
v | vlc  | Paket | 2.0.2-1.9   | i586 | Packman Repository 12.1
i | vlc  | Paket | 2.0.1-12.14 | i586 | (Systempakete)

Warum ist bei mir die "ältere" Version installiert, obwohl ich das Packman Repository mit der höchsten Priorität versehen habe?

Die "neuere" Version wird mir bei YaST / Online Aktualisierung nicht angeboten.

Führe ich z.B.

Code:

zypper lu

aus, so wird mir das Vorhandensein der neueren Version angezeigt. Aber auch alle anderen Pakete mit neueren Versionen, die ich nicht unbedingt alle aktualisieren will, was ja wohl bei

Code:

zypper up

ausgelöst würde.

Beim nächsten Beispiel bietet mir YaST / Online Aktualisierung beim Paket wine richtig die neuere Version an, weil das Repo "openSUSE-12.1-Oss" bei mir eine niedrigere Priorität hat :

Code:

S | Name | Typ   | Version      | Arch | Repository                        
--+------+-------+--------------+------+-----------------------------------
v | wine | Paket | 1.4-2.12.1   | i586 | Aktualisierungen für openSUSE 12.1
i | wine | Paket | 1.3.30-2.1.2 | i586 | openSUSE-12.1-Oss

Warum funktioniert das hier, aber beim ersten Beispiel nicht?

Was ist überhaupt die richtige Update-Strategie?

Apper oder YaST-Online-Aktualisierung oder ausschließlich zypper ?

Wenn zypper, dann aber wie?

Ich würde gerne das Ganze besser verstehen, wobei ich auf Eure Hilfe setze.

Die Informationen, die mir z.B. YaST über "Anbieter", "Paketersteller" und "URL" bietet, sind sicher alle richtig, helfen mir aber nicht wirklich weiter.

Gruss H.

Daß im zweiten Beispiel die "Aktualisierungen" bei mir eine höhere Priorität haben, entspricht wohl nicht den Empfehlungen. Es ist aber im Moment der "status quo". Ich werde das später richtig stellen.

josef-wien · 31 Juli 2012

Die online-Aktualisierung beschäftigt sich - wie Du auch am Reiter erkennen kannst - mit patches, das sind im Umfang reduzierte Pakete, die nur die Änderungen gegenüber der Vorversion enthalten. Packman bietet keine derartigen Pakete an, meines Wissens gibt es sie überhaupt nur für das Update-Repo (das durchaus höher priorisiert sein kann als oss und non-oss, aber nicht sein muß).

halo44 schrieb:
die ich nicht unbedingt alle aktualisieren will

Daher solltest Du "Software installieren und löschen" verwenden, bei der Installationsquelle ("@System" = alle installierten Pakete) nach der Version sortieren und aus den blau geschriebenen Paketen gezielt auswählen.

Move · 11 Aug. 2012

Hallo Herz-von-Hessen.

Vielen Dank für deine Ausführliche Erklärung, jetzt habe ich verstanden wie das mit den Programmen läuft.
Habe jetzt die Prioritäten nach deinen Angaben vergeben.
Eine kleine Frage habe ich noch.
Ich habe in den Repos noch AMD-Treiber, soll ich den löschen oder welche Priorität sollte ich ihm ansonsten vergeben?

Auch allen anderen ein großes Dankeschön!!!!

mfg
Move

Herz-von-Hessen · 12 Aug. 2012

Hallo Move,

Move schrieb:
Vielen Dank für deine Ausführliche Erklärung, jetzt habe ich verstanden wie das mit den Programmen läuft.

Und den Einwurf von lOtz noch dazu.

Move schrieb:
Ich habe in den Repos noch AMD-Treiber, soll ich den löschen oder welche Priorität sollte ich ihm ansonsten vergeben?

Da es für den proprietären Treiber wahrscheinlich eh nur eine offizielle Quelle gibt, und es nach dem installieren desselben keine neuere Version woanders zu erwarten gibt, dürfte dessen Priorität egal sein. Was es nur einmal gibt wird auch nur aus der Quelle geholt.
Lediglich eine Aktualisierung über die Quellpakete (*.run oder tgz und dergleichen) gäbe es schneller/mehr neues - Ist nicht ratsam!

lieben Gruß aus Hessen

Move · 15 Aug. 2012

Jetzt hab ich alles kapiert, Prioritäten richtig vergeben.

Danke in alle für die Hilfe!!!!

Ich stell den Thread mal auf gelöst.

Grüße

Move

[gelöst] Wie Programme immer auf neuesten Stand?

Hacker

Administrator

Hacker

Guru

Hacker

Guru

Moderator

Hacker

Ultimate Guru

Hacker

Guru

Hacker

Guru

Guru

Moderator

Hacker

Ultimate Guru

Hacker

Guru

Hacker