Verständnisfrage zu /etc/vdr/conf.d

Zitat von ludi

Wenn man schon dabei ist, wäre es nicht auch sinvoll, etwas ähnliches für die setup.conf zu tun und die Parameter der Benutzer für die verschiedenen Plugins auch in einzelne Dateien speichern, anstatt alles in die setup.conf zu stecken.

Nein!

Klaus

Zitat von kls

Nein!

Finde ich auch, wozu sollte das gut sein? Ein Plugin muss ja nicht die setup.conf benutzen, sondern kann ja auch eigene Dateien im ConfigDir ablegen.
Die setup.conf ist ja eigentlich nur für eine handvoll Werte gedacht gewesen, wenn ein Plugin eine sehr umfangreiche Konfiguration benötigt, macht eine eigene Datei eher Sinn.

Und mit cConfig usw. gibt es genug Hilfsklassen im vdr, die man dafür benutzen kann.

Lars.

Zitat von mini73

Ein Plugin muss ja nicht die setup.conf benutzen, sondern kann ja auch eigene Dateien im ConfigDir ablegen.
Die setup.conf ist ja eigentlich nur für eine handvoll Werte gedacht gewesen, wenn ein Plugin eine sehr umfangreiche Konfiguration benötigt, macht eine eigene Datei eher Sinn.

Ich hatte da zum Beispiel das xmltv2vdr plugin im Sinn, das sogar die Verknüpfung zwischen den "verbindlichen Sendernamen" und die empfangenen Sender in die Setup.conf schreibt. Wären diese in einer eigenen Datei, könnte man leicht ein Backup davon ziehen.

Ich verstehe jedoch das Argument, dass sich das Plugin selbst drum kümmern sollte; und dies umso mehr wenn der VDR auch das nötige dafür anbietet.

Danke für die Erläuterung.

Da könnte man ja auch das Plugin anfassen und die Konfiguration im Plugin-Verzeichnis abgelegen, am besten so, dass sie sich auch ohne OSD einfach anpassen lässt.

Zitat von Copperhead

Ich habe mir schon ein paar Gedanken gemacht, wie man das lösen könnte. Ich würde das mit Perl lösen. Von der Steuerung direkt angelehnt, an systemctl von systemd.

Also "vdrctl list", "vdrctl enable", "vdrctl disable". Möglicherweise noch "edit"

Ich hab mal eine Diskussion auf der Mailingliste gestartet: http://linuxtv.org/pipermail/vdr/2015-February/028641.html

Was das Doppel-Laden von Plugins betrifft: es sind einfach getrennte Dateien. In meiner Vorstellung arbeitet vdrctl mit den Dateien, nicht mit dem Inhalt oder mit der Bezeichnung bereinigt um die Zahl vorweg. Für die Shell kann man ja ein completion-Script schreiben, was einem bei der Eingabe hilft.

Lars.

Nein. Echt nicht. Wenn ich ein Plugin aktivieren will, dann ist das "vdrctl enable $PLUGINNAME". Und wenn jemand unbedingt ein Plugin zweimal laden muss (wie z.B. bei graphlcd dann und wann üblich), dann nennt man die zweite Config dann halt "50-graphlcd2.conf" und aktiviert das mit "vdrctl enable graphlcd2".

Welchen Vorteil soll die Sache mit den Symlinks genau haben?
Bei mir (Gentoo) sind alle configs der Plugins in /etc/conf.d und es gibt dort noch die vdr.plugins, wo einfach die aktivierten Plugins eingetragen werden, per eselect vdr-plugin enable(disable) Pluginname wird es aus der Liste entfernt oder hinzugefügt, sehr einfach.

Ich finde es auch wesentlich besser, übersichtlicher und letztendlich der Stabilität dienlicher, wenn jedes Plugin seine Startparameter über die jeweilige config mitbekommt, als dass die vdr.conf so aufgebläht wird.

Die Plugins über das OSD ein/ausschalten und eventuell die Startreihenfolge zu ändern fände ich auch sehr praktisch.

Du kannst/sollst ja eine Config pro Plugin anlegen.

Die Idee ist, dass ein Plugin-Paket, wenn es installiert wird, die Config erstmal nach /etc/vdr/conf.avail legt und der Benutzer selbst durch Symlinken das Plugin aktiviert.

Wenn es später mal ein "vdrctl" gibt, dann reicht für den Zweck dann ein "vdrctl enable $PLUGINNAME".

Badenser

Hast du meine Mail gelesen, die ich oben verlinkt habe?

Lars

Zitat von M-Reimer

Die Idee ist, dass ein Plugin-Paket, wenn es installiert wird, die Config erstmal nach /etc/vdr/conf.avail legt und der Benutzer selbst durch Symlinken das Plugin aktiviert.

Das ist mir schon klar, mir geht es um das Symlinken und ob es nicht einfacher ist, so wie bei Gentoo die Plugins über den Eintrag in einer simplen Textdatei zu aktivieren. Ich denke da auch ein wenig an die Übersichtlichkeit (noch nen Verzeichnis für die Symlinks, dann die Symlinks im Verzeichnis...). Das etc-Verzeichnis ist eh schon so voll.

Lars

ja, hab ich und der Ansatz ist echt gut. Muss nur noch ein wenig gefeilt werden und dann sollten noch alle Distris/Maintainer mitziehen. DAS wäre mal etwas, was es noch nicht in der Linux-Welt gegeben hätte, dass nicht jeder sein eigenes Süppchen kocht.

Ergänzung:

das käme wirklich allen Benutzern zugute, weil man wesentlich einfacher Benutzern anderer Distris helfen kann, bzw einem geholfen wird, da zumindest alles, was den VDR betrifft einheitlich geregelt ist.

Der conf.d Patch ist jetzt ja nun so, wie er ist, im vdr. Wenn man jetzt da noch einbauen würde, dass eine zusätzliche Datei, die wieder irgendwo liegt, eingelesen und interpretiert werden muss, dann die schon eingelesenen Argumente nach den Plugins gefiltert werden müssen... Ich sag mal: nö.

Du musst ja nicht mit symlinks arbeiten, du kannst die Dateien auch löschen, wenn du ein Plugin nicht laden möchtest (oder die Datei editieren und alle Zeilen auskommentieren), aber ich halte das Arbeiten mit symlinks für einfacher und verständlicher. Außerdem gibt es zu allen möglichen Programmen solche conf.d-Verzeichnisse, deren Dateien eingelesen, sortiert und verarbeitet werden (grub, apt usw.), warum also einen anderen Mechanismus benutzen?

Bei Debian gibt es auch eine extra Datei zum Deaktivieren von installierten Plugins, aber intuitiv fand ich das nicht. Insbesondere, weil man da nur plugins deaktiviert, aber nicht aktiviert. Dafür reicht es, wenn die so-Datei im Pluginverzeichnis liegt.

Ich hoffe, ich konnte meinen Standpunkt deutlich machen, will dir aber nicht auf den Schlips treten.

Lars

Ich finde das so auch in Ordnung. Ich kenne das von freetype so.

Außerdem habe ich mit vdrctl angefangen und möchte das jetzt nicht wieder alles umstellen müssen.

Lars

ich fühle mir nicht auf den Schlips getreten, ich wollte ja nur wissen, warum es die Symlinks sein müssen, wenn es schon (fast) eine fertige Lösung mit der Datei gibt. Wenn die Gentoo-ebuild-Maintainer auf den Zug aufspringen, bin ich natürlich automatisch mit dabei. Ich habe mich, seit ich Linux benutze, schon an so viel neue Sachen gewöhnen müssen, da wäre dies Pillepalle.

Wichtig ist, dass es gut durchdacht und schlank ist und dass alle mitmachen, dann gewinnt jeder.

der Badenser

übrigens, Badenser sagen nur Schwaben, wir sind Badener

Vorher gab es x Lösungen für dieses Problem, deshalb hab ich eine x+1. Lösung gebaut.
Meine hat den Vorteil, dass ich sie in den vdr bekommen habe.

Jetzt können die ersten x Lösungen so nach und nach verschwinden bzw. die jetzt offizielle Lösung adaptieren.
Für den vdr kann ich mir keine Erweiterung vorstellen, weil es vom Standpunkt des vdr einfach und übersichtlich ist. Wie man die Dateien nur von außen organisiert... spielt nicht wirklich eine Rolle. Ich hoffe aber, dass ein paar auf den symlink-Zug aufspringen.

Zusammen kriegen wir das schon hin.

Lars

Hi
Vielleicht denke ich jetzt falsch, aber ich verstehe den Sinn der Diskussion nicht
Wo ist denn der große Unterschied zwischen EINER Datei wo die aktivierten Plugins drin stehen und EINEM Ordner wo die aktivierten Symlinks drin sind???

Für ein Skript das die Aufgabe des de-/aktivierens übernehmen soll ist es doch auch das selbe Handling:

Aktivieren -> Plugin in Datei schreiben --------- Plugin Symlink erstellen
Deaktivieren -> Plugin aus Datei entfernen --------- Plugin Symlink entfernen

Für mich ist das vom Prinzip her identisch

Gruß Patrick

Das Ergebnis ist sicherlich identisch, der Weg aber Geschmackssache.
Und beide sind gültig.

Was Badenser aber eigentlich meint, ist, dass die Konfiguration, also die Parameter für die Plugins, in einzelnen Dateien liegen, aber ob ein Plugin geladen wird, in einer anderen Datei. Ich persönlich finde es eine Ebene zu kompliziert.

Letztendlich startet ein vdr mit den Einstellungen, die man gerne haben möchte.

Lars

Kompliziert ist es eigentlich nicht, nur der Weg ein Wenig anders. Wie Patrick schon gesagt hat, ob ich jetzt einen Symlink zur Config anlege oder den Pluginnamen in eine Datei eintrage bewirkt im Endeffekt das selbe. Das mit den Symlinks lehnt sich halt an das klassische Init-System an und wird wahrscheinlich für die meisten User (zumindest diejenigen, die von Linux eine Ahnung haben) einfacher sein, da schon bekannt.

Wie wir im Süden sagen, wichtig ist, was hinten raus kommt.

So say we all.

Lars

Zitat von Badenser

übrigens, Badenser sagen nur Schwaben, wir sind Badener

alles Gelbfüßler

Gruss,
S:oren

Hallo zusammen,
nachdem viel drüber geredet wurde habe ich mal einen Entwurf gebaut.
Die von Lars beschriebenen Funktionen sind soweit ich das getestet habe umgesetzt. Das Programm unterstützt es auch die gleiche Datei mehrfach zu aktivieren, dann allerdings mit verschiedenen Prioritäten. Dieses Verhalten muss aber explizit über --secondary aktiviert werden. Standardmäßig wird bei Bedarf die Priorität geändert.
Zudem ist eine Option status hinzugekommen, welche ebenfalls den Basisnamen erwartet.

Eine Einschränkung gibt es aktuell, bei den verfügbaren Dateien darf es einen Basisnamen, also das zwischen (optionaler) Priorität und der .conf-Endung, nicht mehrfach geben. Möchte man ein Plugin mehrfach mit unterschiedlichen Optionen einbinden kann man das entweder in eine Datei schreiben oder die Datei muss im Quellordner auch anders heißen. Nur eine andere Priorität genügt nicht.

Dateien, die nicht dem vorgegebenen Schema entsprechend werden, je nachdem wo sie liegen, entweder ignoriert oder per Warnung bemängelt.

Nicht nur die klassischen Init-Systeme nutzen diese Variante, auch systemd macht stark davon Gebrauch - allerdings ehr im Hintergrund, wie es mit vdrctl auch gewollt ist. Ebenso gibt es einige Distributionen die z.B. für den Apache darauf setzen. Es gibt noch diverse weitere Beispiele in die Richtung.

Clemens