Bei der Suche nach installierten Paketen finde ich dies übersichtlicher:

$ pacman -Ss firefox | grep Installiert
extra/firefox 114.0.2-1 [Installiert]
extra/firefox-i18n-de 114.0.2-1 [Installiert]

Zudem siehst du bei der Suche mit -Ss auch die Beschreibung gleich, und musst nicht jedes Paket auswählen.

Aber das ist ja das Schöne an den vielen Optionen, jede*r kann das nutzen was ihr/ihm am besten gefällt.

Dirk Ohne jetzt die Hilfe aufzurufen, wofür die Option «e» steht, sieht mir die ausgegebene, ungegreppte Liste verdächtig nach Paketen aus, die ich manuell installiert habe. Demnach müsste das «e» für explicit stehen, und wenn ich jetzt das «e» durch ein «d» (wie dependency) ersetze, müsste die ausgegebene Liste nur Abhängigkeiten enthalten.
.
.
Edit:
———

Einen Test, und einen Blick in die Man–Pages später, kann ich sagen, dass ich mit meiner Theorie recht hatte. Jetzt stellt sich die Frage, woher ich das wusste, wenn ich diese speziellen Querry Commands noch nie verwendet habe.
Die einzigen Querry Commands, die ich bisher benötigt habe, sind -{S|Q}s und -{S|Q}i.

Sunshine Da ist das Browsergefummel zwecks Orientierung für mich angenehmer. Wenn ich aber unter pacseek firefox eingebe, sehe ich welches Paket aktuell aus welchen Repo installiert ist und viele weitere nützlichen Infos zum Paket.

Es spricht nichts dagegen pacseek zu benutzen. Du entscheidest selbst, was für dich praktisch ist.
Die lange Ausgabe auf der Konsole ist tatsächlich nicht sehr attraktiv. Mich erinnern deine screenshots von pacseek an Synaptic einen graphischen Paketmanager den ich gerne bei Debian genutzt habe als mir die Konsole noch nicht sehr vertraut war.
Aber wie @schard schon so treffend bemerkte:

#p388373 pacseek nutzt unter der Haube auch nur pacman via LIBALPM bindings. Also nur ein weiteres pacman GUI.

Was dann eben auch bedeutet, dass pacseek weder mehr Funktionen noch bessere Informationen zu bieten hat. Es ist wohl eher die graphische Darbietung die dich bei pacseek aktuell mehr anspricht.
Zu bedenken ist, dass du dir bei pacseek Tastaturbefehle einprägst, die nur dort gebrauchen werden, während der direkte Umgang mit pacman im Laufe der Zeit auch schult pacman für sehr spezielle Aufgaben gezielt einzusetzen. Auch kann ein wenig 'Konsolenvoodu' mit |grep nicht verkehrt sein um eine lange Ausgabe auf der Konsole auf das Gesuchte zurechtzustutzen.

Ich denke mal, es spricht nichts gegen pacseek, aber im Laufe der Zeit erkennt man, dass man mit pacman sehr viel treffender und dazu auch noch schneller an das jeweils gewünschte Ziel kommt. Aber das ist wohl auch eine Erfahrungssache.

stefanhusmann Ich habe ein paar Einwände.

Dann sollte man wohl die Finger von diesem Tool lassen!

Hier noch ein paar Tipps für Sunshine:

Wenn man #Color in der /etc/pacman auskommentiert, zeigt pacman seine Ausgabe in Farbe an.
Das kann helfen eine bessere Übersicht zu bekommen. (Die Anzeige [Installiert] springt dann richtig ins Auge)

Installierte Pakete:

pacman -Q - Alle installierten Pakete.
pacman -Q |less - seitenweise Anzeige.
pacman -Q firefox - Ist firefox installiert? Version?
pacman -Q |grep fire - alle installierten Pakete mit "fire" im Namen.
pacman -Qs fire - Bei 's' genügen auch Namensbestandteile für die Suche.
pacman -Qs fire Browser - Ein Browser mit "fire" im Namen. Die Paketbeschreibung ist Teil der Suche.

Pakete aus dem Arch Linux Repository:

(Die Suche funktioniert genauso wie bei bei -Qs)
pacman -Ss fire lang de - Auch mehrerer Namensbestandteile sind möglich (ohne *).
pacman -Ss fire germ - Findet wie oben das deutsche Sprachpaket.
pacman -Ss fire add - Zeigt die verfügbaren firefox addons.

Paketinformationen (hier firefox)

pacman -Qi firefox oder pacman -Si firefox

Es ist sehr schwer pacman zu toppen. Mit ein paar Kniffen kann man seine Suche sehr gezielt gestalten und lange Ausgaben vermeiden. Und wenn dieses Tool nicht gut gewartet ist, dann lohnt sich das nicht wirklich.

Es ging in dem Fall nicht um ein Paket, dass sich nicht bauen ließ, sondern darum, dass pacseek erst gar nicht angefangen hat, es überhaupt zu versuchen, weil es offenbar die conflicts/provides-Felder nicht auswertet. Das ist eine so basale Anforderung, dass ich gar nicht wissen möchte, was alles schief geht, wenn die Anforderung etwas weniger allgemeingültig ist.

Ich möchte auch gar nicht grundsätzlich in Abrede stellen, dass mafür gewisse Usecases/Angewohnheiten ein solches Tool seine Berechtigung hat, und immerhin scheint der Autor auf Bugreports flink zu reagieren. Ich kann aber nur davor warnen, es im gegenwärtigen Zustand unbesehen zu benutzen. Dazu ist es noch zu unfertig.

yay wird nicht automatisch mitinstalliert, aber die Default-Konfiguration sieht es halt vor, und alle Versuche, etwas mittels pacseek zu installieren, scheitern halt, wenn yay nicht da ist.

Dass die Configdatei im Userdir liegt, fand ich auf Anhieb gar nicht so schlimm, aber nach längerem Nachdenken ist der Einwand komplett berechtigt. Paketinstallationen sind root-Sache.

Ich hab noch ein wenig geforscht, wie man die Ausgabe einer Paketsuche an seine Bedürfnisse anpassen könnte und bin dabei auf expac gestoßen.
Expac ließt die pacman db aus und bietet viele Möglichkeiten die Ausgabe zu gestalten.
Und zwei kleine Skripte sind auch gleich entstanden.

pkS für die Suche im Repo:

#!/bin/bash
#->file /usr/local/bin/pkS

echo "Search Arch-Linux-Repository:" 
read Regex

expac -Ss '%-30n  %-10v  %d' ${Regex} 

Und pkQ für die Suche nach installierten Paketen:

#!/bin/bash
#->file /usr/local/bin/pkQ

echo "Search installed packages:" 
read Regex

expac -Qs '%-30n  %-10v  %l  %d' ${Regex}

Nah ja, eine Spielerei. 😉

Edit: Habe bei pkQ noch ein%l hinzugefügt. So schreckliche Fragen wie: "Wann zum Teufel hab ich denn das installiert?" Gehören damit dann der Vergangenheit an.