firefly wrote:schmidicom wrote:Ich vermute mal du meinst die Datei "/usr/share/doc/pcsc-lite/setup_spy.sh.bz2"?
ja die meine ich
Kannst du da mal dein Repo verlinken? Würde mir den Patch, so aus neugier, gerne mal ansehen.
firefly wrote:schmidicom wrote:
Was mich am ebuild im Repo von Gentoo besonders gestört hat war die udev Regel.
Das in der Regel hinterlegte Service-Unit macht einfach keinen Sinn, weder für jene die OpenRC noch für jene die systemd benutzen. Unter OpenRC gibt es kein Service-Unit das an dieser Stelle gestartet werden könnte und unter systemd gibt es das Socket-Unit welches dafür sorgt das der Dienst bei Bedarf gestartet wird und das ausgeführte Shell-Script ist unter systemd auch nutzlos.
Das file macht schon so "sinn" da es "generisch" ist. z.b. das shell script hat nen check ob es unter openrc läuft oder nicht und macht gar nichts wenn es nicht unter openrc läuft.
Und der andere part setzt nur eine env variable, das macht dann im kontext von openrc auch nichts da diese ENV variable systemd spezifisch ist.
Dadurch hast du nur eine regel, die im kontext von openrc und von systemd funktioniert.
Wobei man natürlich darüber diskutieren kann, ob das starten des services via udev rule im kontext von systemd noch sinvoll ist da es die socket activation systemd unit gibt.
Das Script führt zwar einen Check durch, aber trotzdem wird es bei jedem Start des Systems und jedesmal wenn eine Smartcard angeschlossen wird zusammen mit seinem Interpreter (was in den meisten fällen die Bash sein dürfte) ausgeführt und das ist über das ebuild (in Fällen wo es das nicht braucht) mit wenig Aufwand vermeidbar. Das ganze Ding ist auf Installationen mit systemd auch eine unnötige Fehlerquelle die vermieden werden kann und auch vermieden werden sollte.
Hier mal eine Liste an möglichen Szenarien die mir dazu so spontan einfällt:
- * Was passiert wenn das Verzeichnis "/run/openrc" auf einem Gentoo mit systemd, aus welchen Gründen auch immer, doch vorhanden ist?
* Was ist wenn das Shebang "/bin/sh" nicht mehr funktioniert weil durch merged-usr eventuell der Pfad nicht mehr gültig ist?
* Was ist wenn "sh" auf eine andere Shell verlinkt wurde die eventuell mit der Syntax nicht klar kommt?
Ich sehe hier keinen Grund warum nicht zwei verschiedene, auf den jeweiligen Fall optimierte, udev-Regeln bereit stellen sollte. Und das könnte auch auch von den Gentoo-Devs noch einfacher gemacht werden wenn die eclass
udev eine Funktion bekommen würde mit der man solche Regeln nicht nur installieren sondern auch direkt aus dem ebuild heraus erstellen könnte (ähnlich wie die Funktion "make_desktop_entry" aus der eclass
desktop).
Und ja das starten von "pcscd.service", über eine udev-Regel, unter einem Gentoo mit systemd ist halt wirklich komplett sinn frei weil das Service-Unit mit dem Socket-Unit verknüpft ist. Bedeutet folgendes: Wenn das Service-Unit auf diese Weise gestartet wird wird auch das Socket-Unit gestartet und wenn der Dienst dann von niemanden verwendet wird wird das Service-Unit wieder automatisch beendet. Ein potenzieller Leerlauf...
Das einzige was an dieser Stelle eventuell Sinn machen würde wäre das Socket-Unit über die udev-Regel zu starten, aber auch das sollte eigentlich der Entscheidung desjenigen überlassen werden der/die für das jeweilige System verantwortlich ist. Bei anderen Packages wird das auch so gemacht und dann im Wiki erwähnt das man nach der Installation eventuell mit "systemctl" noch das Socket-Unit aktivieren sollte.
firefly wrote:Eine system user unit ergibt nur sinn, wenn man pcscd dann nur auf ein spezifisches gerät fest pinnt (Was AFAIK sogar geht via filter?). Denn nur so können mehrere user, welcher unterschiedliche devices nutzen, ihre eigene instanz haben.
Aber dann müsste man dem system irgendwie mitteilen können welche devices zu welchen user "gehören".
Was aber wieder zu Problemen führen kann, falls Benutzer A dann doch mal sein device im kontext des Benutzers B nutzen muss/möchte.
Das verwenden von pcscd als User-Server ist aktuell halt einfach keine gute Idee aber auch nichts was ich jetzt unbedingt haben müsste. Es ist halt nur so das bei einem Blick in die "meson.options"-Datei zu vermuten ist das der Entwickler diese Variante bevorzugt. Nur bin ich halt der Meinung das die Software dafür noch nicht bereit ist.
