Arch Linux

pacman - Option gesucht

mannohneschuh

Hi,
entschuldigt den komischen Titel, aber mir ist keine besserer eingefallen.
Mein Problem ist folgendes: Wenn ich 'pacman -Qu' aufrufe dann bekomme ich alle Pakete aufglistet für die es neue Versionen gibt. Dahinter steht dann die aktuelle Versionsnummer. Ist es möglich auch die Versionsnummer, auf die aktualisiert wird, anzuzeigen?
So das aus

pacman -Qu
claws-mail 3.7.7-1
claws-mail-extra-plugins 3.7.7-1
lib32-libogg 1.2.0-4
libogg 1.2.0-1
libvorbis 1.3.1-1
ttf-dejavu 2.30-2

zB das wird

pacman -Qu
claws-mail 3.7.7-1 -> 3.7.8-1
claws-mail-extra-plugins 3.7.7-1 -> 3.7.8-1
lib32-libogg 1.2.0-4 -> 1.2.1-1
libogg 1.2.0-1 -> 1.2.1-1
libvorbis 1.3.1-1 -> 1.3.2.-1
ttf-dejavu 2.30-2 -> 2.32-2

Vielen Dank für die Aufmerksamkeit.

Edit: Thema geschlossen
BTW: eigentlich wars cool sowas in pacman direkt (als Option) zu haben. Sieht noch jemand nen Sinn darin? Vielleicht mal als Denkanstoß an die Dev's schicken.

linux-ka

Ich meine, dass das bei yaourt der Fall ist, wenn man nen upgrade fährt. Wenn dies jedoch nur zur info dienen soll, dann muss man dort jedoch den kompletten Vorgang abbrechen. aber schau doch im bash skript von yaourt nach wie es dort gelöst ist. dann kannste das bei nem alias einbauen.

GerBra

Ganz auf die Schnelle ein Einzeiler (als alias z.B.)

ruby -e 'IO.popen("sudo pacman -Qu").readlines.each {|package| puts package.chomp + " -> " + IO.popen("pacman -Si #{package.split.first.strip} | grep Version").readlines.first.split(":").last.chomp.strip }'

//edit: Oder als Shellscript-Einzeiler:

IFS="";for i in $(pacman -Qu); do echo -n $i; echo -n " -> "; echo $(pacman -Si $(echo $i|cut -d' ' -f1)|grep 'Version')|cut -d':' -f2; done

mannohneschuh

Danke GerBra. Funktionieren beide perfekt. Werd wohl die Shellvariante nehmen (keine größeren Abhängigkeiten)

GerBra

Ich könnte mir vorstellen daß es dazu schon einen FeatureRequest im Bugtracker(->pacman) gibt - oder gab, und dieser eben verworfen wurde. Kannst bei Lust und Zeit ja mal stöbern/suchen.
Ob man diese Information direkt bei -Qu haben will (was ja, wie in den Einzeilern pro updatefähiges Paket einen zusätzlichen Abfragezyklus braucht) oder eventuell mit dem -v Schalter kombiniert, wäre ja egal...

Andererseits haben wir in Linux die wunderbare Möglichkeit stdout(die Ausgabe) durch (fast) alle vorstellbaren Pipe-Kombinationen zu schicken - wobei auch eher Phantasie als umfangreiche (Shell)-Programmierkünste nötig sind.
So ist "Sebstgemachtes" halt oft wesentlich flexibler als Vorgegebenes - man könnte z.B. obigen Ansatz auch um Abfragen in der pacman.log erweitern und zusätzlich eine Art Versionshistorie mitausgeben lassen.....

Gerade aufgrund eben dieser Möglichkeiten ist IMHO der Ansatz: "wir beschränken uns im Hauptprogramm auf das Wesentliche" auch nachvollziehbar.

//Edit: Deswegen bin ich z.B. auch gegen eine Datenbank als "letzte Instanz" für alle Paketinformations-Daten. Die bisherige Verzeichnissstruktur als Basis ist halt absolut fehlertolerant - aber auf Kosten der Performance.
Die diversen Ansätze mit einer Datenbank(sqlite z.B.) als Zwischenschnittstelle für alle Abfrageoptionen find ich allerdings ok, aufgrund SQL eröffnen sich dann auch ganz andere, einfachere Zugänge zu den Daten. Aber Grundlage der Datenbank(konsistenz) sollte halt immer die "Verzeichnissstruktur/Infos" sein.
Deshalb vermisse ich bei pacman eher die Optionen vor/nach bestimmten Operationen eben (externe) Aktionen starten zu können, also eine Art beforeCmd / afterCmd, welches als verarbeitbare Actions eben auf -Sy und -Su signalisiert.
Da würden sich dann viele neue Funktionen denken lassen...