Danke für die Ge"danke"n ;.)
FW Paket aus dem AUR
tuxnix etzt wird jeweils nur noch das installierte AUR Paket angezeigt, weil pacman was gefunden hat, aber die Suche mit pkgfile nicht mehr stattfindet. Das ist ein klein wenig schade, denn dann erhält man keine Information mehr darüber, dass ein reguläres fw-Paket die Sache auch erledigen könnte.
Es wäre eine Überlegung, bei der ganzen Suche nach passenden FW-Paketen ggf. auf die pacman -Qqo Abfrage ganz zu verzichten. Und alles/generell über pkgfile abzuwickeln. Die vorhergehende pacman-Abfrage war ja vornehmlich um den Ablauf zu beschleunigen als dann noch die "langsame" pacman -Fx folgte. Das ist mit pkgfile ja nun kein Problem mehr.
tuxnix Ich würde jedoch das "(installed) /(not installed) schon oben reinschreiben. Das spart unten auch eine erneute Abfrage mit pacman -Q. Wenn oben mit dabei steht was schon installiert und nicht installiert ist, dann wird die Zuordnung einfacher.
Das Summary könnte dann evnt. auch ganz weg.
Eigentlich habe ich das Summary von Anfang an geliebt, es vermittelt so was von fast "Meister Yoda"-hafter Weisheit. Junger Paddabhan, installieren du musst...
Käme halt auch auf die Länge der Ausgabe an, ob das Scrollen noch sinnvoll, "Spaß macht". Leider kenne ich halt bisher nur sehr wenige (die aus dem Thread halt) Ausgaben vom Skript, wie das also bei anderen "aussieht". V.a. wenn ggf. noch mehr USB/BT Geräte aktiv sind.
Aber ja, ist ein Gedanke wert.
//Edit: ganz vergessen:
tuxnix Andersherum, wenn ein fw-Paket installiert ist, aber dyndbg keine Meldung wie z.B 'tg3 * Loaded FW' hergibt, dann kann man davon ausgehen, das das Paket unnötiger Weise intalliert wurde.
Auch ein Gedanke.
Allerdings erfordern diese ganze Dinge eigentlich eine fast komplette Neuorganisation des "Ablaufs" und v.a. der Ausgabe/Auswertung. Das wäre eine wahre V5 ;-)
Die nächsten 1,2 Wochen hatte ich eigentlich vor mich nicht mehr groß damit zu beschäftigen. Wenn also, dann kann es einige Zeit dauern.
Anderer "Einwand" gegen diese ganzen "neuen Ideen": Ich schreibe im Readme ja auch, daß die Aussage: die und die Pakete werden benötigt ggf. nur bedingt (also nicht 100% als Muß) zu werten sind. Sondern eher dahin: Auf welche von den im Meta-Paket angeführten kann ich nach diesen Angabe dann verzichten.
Bei dir mit tg3: Du würdest dann das broadcom Paket behalten(oder auch installieren) obwohl du es nicht wirklich brauchst(dyndbg). Aber du könntest aber auf zig der anderen Pakete dann verzichten anhand der Skript-Aussage. Ich meine: allein dieser Ansatz ist doch schon etwas...
Zum "angedrohten" Anschlag:
tuxnix Das ließe sich beheben indem man lspci mit einbezieht.
Wenn für das Modul noch kein passendes Paket installiert ist und lspci meldet, dass das Modul schon in use ist, dann braucht es dafür auch gar kein fw-Paket.
(Das spart dann auch eine aufwendige Suche mit pkgfile ein)
Ja, hatten wir ja schon mal andiskutiert. Damals noch als Vorschlag von dir, diese Abfrage als "Grundgerüst" eines Skripts zu nehmen. Da hatte ich ja schon Bedenken angemeldet. Die halte ich auch weiterhin aufrecht, siehe ¹ unten.
Was ich mir vorstellen könnte wäre diese Prüfung ins bestehende Konzept zu integrieren (siehe auch ²). Also weiterhin:
Prüfe alle geladenen Module:
-> Braucht das eine Firmware(modinfo=
-> Ist dieses Modul per lspci auswertbar(auf in use)
-> Suche das Paket
Ich bin mir nur noch nicht ganz im klaren, was mit dieser lspci-Abfrage/Aussage dann festgestellt werden soll...
Gut: modul tg3 will linux-firmware-broadcom, pacman -Qo sagt: ist nicht installiert, lspci sagt: älläbäh, trotzdem in use - ergo: du braucht das Paket nicht? Ist das hilfreich für einen User? Kann man das in den Ausgaben "vermitteln"? Bin ich unsicher...
Zu ¹ :
https://0x0.st/PHGZ.txt
Das sind im 6.18 die Module (mit Description) die eine Firmware referenzieren. Wenn du die Desc. überfliegst, siehst du schon daß ein Großteil mit Sicherheit nicht bei einer lspci Abfrage auftauchen würde. Da eben BT/USB/FW oder sonstwas(onboard aber nicht am pci-bus). Oder Hardware für die das Modul sowohl für PCI als auch für eben Nicht-PCI verwendet würde.
Deswegen sagte/sage ich: als Grundlage für das Skript kein Ansatz.
Zu ²:
Auch den ganzen PCI-Bus zu scannen (while read <<lspci) macht IMHO wenig Sinn.
Bei mir:
$ lspci -k|grep "in use"
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: piix4_smbus
Kernel driver in use: k10temp
Kernel driver in use: xhci_hcd
Kernel driver in use: ahci
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: pcieport
Kernel driver in use: r8169
Kernel driver in use: nvidia
Kernel driver in use: snd_hda_intel
Kernel driver in use: ccp
Kernel driver in use: xhci_hcd
Kernel driver in use: snd_hda_intel
Davon brauchen aber nur 3 Module auch Firmware. Das "Verhältnis" dürfte fast überall gleich sein.
Eine Abfrage des lspci lohnt sich also meiner Meinung nach nur ergänzend innerhalb einer lsmod Schleife.