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

    Ich denke, wir sollten das den jeweiligen Distributoren überlassen, ob da nun Hilfetexte drin stehen oder nicht. Wirklich wichtig ist das nicht.


    Solange Copperhead bereit ist, den extended mode in vdrctl weiterhin zu pflegen, ist es für mich in Ordnung. Dann macht die simple Methode aber eigentlich keinen Sinn, weil man mit der extended Methode auch conf-Dateien mit Hilfetexten bearbeiten kann. Und man würde sofort sehen, wenn sich etwas an der Hilfe geändert hat.


    Wenn es aber darauf hinauslaufen sollte, dass der extended mode verschwindet, dann würde ich die Pflege übernehmen.


    Lars

    Zitat von olebowle

    Also ich würde auch eher die Extended Methode vorziehen. Das erleichtet eigentlich nicht nur deine Arbeit, weil du die configs nicht anpassen musst, sondern auch die der User, weil sie keine .pacnews einpflegen müssen. Wo seht ihr die Vorteile von simple?


    Ganz einfach das es vorteilhafter ist Kommentare und Konfiguration "verzahnen" zu können. Bei wenigen Konfig-Optionen mag das noch ohne gehen aber ab einer gewissen Menge müsste man dann zum Lesen der Doku erst scrollen.


    Bei neuen Optionen gibt es dann das gleiche Problem, das auch bei hunderten anderen Daemons und Unix-Tools so ist: Man hat die neue Konfigurationsdatei parallel und muss diese ggf. übertragen. Das ist für all die anderen Programme gängige Vorgehensweise. Warum gerade beim VDR einen Bruch machen?


    Zitat


    Apropos config aktuell halten: Ich hab gerade mal die wenigen Plugins (vdr-femon, vdr-skindesigner, vdr-softhddevice, vdr-streamdev), die ich installiert habe durchgeschaut. Und es stellt sich raus, dass selbst bei mir schon 2 Plugins nicht den letzten Stand haben: vdr-skindesigner und vdr-softhhdevice. Wollt ihr das auf Dauer wirklich antun?


    Solange du keine neue Konfigurations-Option nutzen willst ist da doch nichts problematisches dabei. Durchsuche doch mal das gesamte /etc nach ".pacnew".


    Zitat


    PS: vdrctl edit vdr geht nicht, weil er ja nur in conf.avail sucht.


    Unabhängig davon, dass das nicht geht: Gutes Beispiel *gegen* den "extended mode". Wer will wirklich ständig hoch und runterscrollen? Da mache ich mir doch lieber die man-page in einer zweiten Shell auf...

    Zitat von mini73

    Dann macht die simple Methode aber eigentlich keinen Sinn, weil man mit der extended Methode auch conf-Dateien mit Hilfetexten bearbeiten kann. Und man würde sofort sehen, wenn sich etwas an der Hilfe geändert hat.


    Stimmt eigentlich auch wieder.


    Das einzige wirkliche Argument, dass ich gelten lasse ist, wie M-Reimer schon geschrieben hat, das verzahnen der Parameter. Settings zwischen die Hilfetexte schreiben. Und im Grunde genommen lasse ich das auch nur bei der Config für die VDR-eigenen Settings gelten (00-vdr.conf) Wenn ein Plugin 5 Parameter hat, ist das viel. Ein Standardterminal ist 80 Spalten x 24 Zeilen. Da ist mehr Platz, als man erstmal erwartet.


    Man könnte eine Zwischenlösung machen und die Conf vom VDR mit Hilfetext und die Pluginconfs ohne.
    M-Reimer: Wie wäre das?

    Um die Dateien zu unterscheiden, ist doch wieder Code nötig.
    Wenn dir vdr.conf (können auch mehrere sein) so lang ist, dass man die "online"-Hilfe gar nicht sieht, weil sie unten dran ist, warum sollte man sie weglassen?


    Lars

    Ich habe nirgendswo .pacnew, weil ich die immer fleißig merge. :] Wie gesagt, ich an sich hab kein Problem mit simple. Dann wäre es aber super die confs Upstream zu bekommen. Ich wollte euch nur das Problem, der Instandhaltung nochmal vor Augen führen.


    Aber mal was ganz anderes und nicht hauen jetzt :) : Warum legt man die paketierten confs nicht nach /usr/lib/vdr/conf.d und linkt die nach /etc/vdr/conf.d? Systemd macht das ja ähnlich mit /etc/systemd/system und /usr/lib/systemd/system.

    Zitat von mini73

    Um die Dateien zu unterscheiden, ist doch wieder Code nötig.
    Wenn dir vdr.conf (können auch mehrere sein) so lang ist, dass man die "online"-Hilfe gar nicht sieht, weil sie unten dran ist, warum sollte man sie weglassen?

    Achso das kam nicht richtig rüber. Ich dachte schon an den Extended Modus, aber eben die Config-Datei wie jetzt. Das die VDR-Configdatei die Einzige ist, die neben den "Onlin" Hilfetexten auch noch die normalen hat.



    Zitat von olebowle

    Systemd macht das ja ähnlich mit /etc/systemd/system und /usr/lib/systemd/system.

    In den systemd.service Dateien wird aber auch nichts editiert.

    Zitat von mini73

    Ok, was ist denn der Unterschied zwischen formatiert und unformatiert?

    So ist es momentan (sogar farblich hervorgehoben):


    So schaut es beispielsweise mit dem --enabled switch aus:

    Code
    $ vdrctl list --enabled
femon
skindesigner
softhddevice


    Folgende Funktionalität hätte ich gern, um die bash-completion ein bisschen zu vereinfachen:

    Ok.


    Bei list würde ich die unter Ausgabe erwarten, das obere sieht mir eher nach "vdrctl status" aus, was wir noch nicht in der Spec haben, aber eine gute Idee ist.


    Lars

    Copperhead


    Ich hab dir einen Pull Request für den extended-edit-Branch geschickt, der "list --all" in "status" umbenennt.
    https://github.com/CReimer/vdrctl/pull/2


    Alle conf-Dateien anzeigen:

    Code
    vdrctl list


    Alle conf-Dateien mit ihrem Status anzeigen:

    Code
    vdrctl status


    "list --all" gibt's dann nicht mehr.


    Was hälst du davon?


    Lars.

    Danke!


    Das "list" ist ja auch in erster Linie für die bash completion interessant.
    Die Ausgabe von "status" war eine gute Idee, die muss ich noch in die Spec schreiben. :)


    Lars.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden