Das binäre Resourcen am besten woanders aufgehoben sind, ist sicherlich noch am verständlichsten. Das wäre die einzige Änderung, der ich zustimmen würde.
Damit sind wir schon zu zweit. Frage ist nun noch, ob Maniac das gleiche gemeint hat und wer das letztlich umsetzen will. Ich habe mich schon angeboten, lasse Maniac aber gerne den Vorrang.
Ich sehe schon das es unterschiedliche Auffassungen gibt was wo liegen sollte. Hier sollten wir uns vor einem Patch einigen wie die Dateistruktur genau aufgebaut werden sollte.
Gibt es eine Liste welche Dateien ein ungepatchter VDR verwenden kann?
Da man den FHS teilweise anders auslegen kann, müssten wir gemeinsam vorher prüfen welche Datei nun in welches Verzeichnis kommt, gerne mit Begründungen dazu.
Wenn wir uns da einig sind, würde ich einen entsprechenden Patch schreiben. Auf das Angebot die Doku in der plugin.html zu übernehmen würde ich dann gerne zurückkomen. Bin eher Programmierer als Doku-Schreiber 
Ich sehe schon das es unterschiedliche Auffassungen gibt was wo liegen sollte. Hier sollten wir uns vor einem Patch einigen wie die Dateistruktur genau aufgebaut werden sollte.
Warum? Warum das nicht per Makefile konfigurierbar machen? Default ist weiterhin ConfigDirectory(), und bei Bedarf kann man per Kommandozeile/make.config nen Basisverzeichnis für die Resourcen (da sind sich hier wohl alle einig das zumindest die Resourcen raus sollten) festlegen. Es gibt ja nicht nur die Distributionen die sich nach der FHS richten, es gibt ja auch die abgespeckten Busybox mini Distros für DOMs.
Und für den VDR ist ja eigentlich nur das "themes" Unterverzeichnis Resource.
Das grosse THema sind ja die Plugins (Burn mit dem ./skins und ./fonts; live mit seinen Resourcen Unterverzeichnissen usw.).
cu
Eben so sehe ich das auch.
Ich merke schon: Wir sprechen von etwas anderem.
FHS-Konform wird der VDR selber eher nie werden! In Standardeinstellung verwaltet der VDR alle seine Daten in seinem eigenen Baum. Hat sicher auch seine Vorteile.
Für FHS wird man auch in Zukunft eine passende "Make.config" brauchen.
Wovon ich rede ist schlicht die Möglichkeit, den Plugins einen zweiten Pfad verfügbar zu machen, der dann "Readonly" definiert wird. So würde es endlich aufhören, dass Bildchen oder ähnliches im "ConfigDirectory" abgelegt werden.
Also ich bin da auch eher einfach gestrickt...
* Eine Partition mit ca. 400GB unter /video (fuer Aufnahmen, schneiden, MP3s, usw., so 'ne Art 'scratch-space')
* Dann die zweite Platte (2TB) unter /video/archive (per Symlink) (alle Filme die ich geschnitten habe und behalten will. Das ganze mit 2 grossen Subdirectories mit jeweils ca. 750GB an Daten. Die beiden Directories kann ich prima auf meine beiden externen per USB anschliessbaren 1TB Platten zum Backup kopieren)
* Die ganzen conf Dateien des VDR unter /video/conf (ich will die schliesslich auch alle wiederfinden!)
Meine beiden Clients mit relativ wenig Plattenplatz mounten dann die o.g. Verzeichnisse read-only per OSD in ihren jeweiligen /video Ordner
FHS ist 'ne schoene Sache, aber beim VDR hab ichs lieber so gestrickt... Und der Vorteil fuer mich: Wenn ich mir ein neues Linux aufspiele, dann muss ich nicht noch eine Menge Sachen konfigurieren oder rumkopieren. Bleibt alles am alten Platz...
PS: Achso, nochwas: Von so Sachen wie /video.00 und /video.01 zum aufteilen der einzelnen Filme auf mehrere Platten habe ich schon immer die Finger gelassen. Nach dem schneiden kommt der Film per 'cp -r ...' ins Archiv, ich hatte frueher auch mehrere 'Archivplatten' im Rechner. Die waren dann halt in Kategorien aufgeteilt (z.B. Komoedie, Sonstige, ...). Macht einem das Leben viel leichter bei umbauten am Rechner...
FHS ist 'ne schoene Sache, aber beim VDR hab ichs lieber so gestrickt... Und der Vorteil fuer mich: Wenn ich mir ein neues Linux aufspiele, dann muss ich nicht noch eine Menge Sachen konfigurieren oder rumkopieren. Bleibt alles am alten Platz...
Die Idee ist ja das per Default alles beim alten bleibt (wenn ich das recht verstehe). D.h. per Kommandozeile "--config=dir" und alles wird dort erwartet (bis auf die Plugins die das eh ignorieren und fix /etc/vdr im Quellcode stehen haben).
Zusätzlich dann jetzt halt nen "--data=dir" (oder wie auch immer) und die Plugins können neben configdirectory() noch datadirectory() (was configdirectory() liefert wenn --data-dir nicht gesetzt ist) nutzen.
Ich glaube so ist hier der allgm. konsens? Oder nicht? Das ist ja nicht ganz perfekt (im FHS Sinn), aber schon mal ne schöne Sache mit der vermutlich alle glücklich wären. Ich fänds so jedenfalls schonmal super (dann kämmen die ersten 30 MB aus dem Config Dir raus ).
cu
Die Idee ist ja das per Default alles beim alten bleibt (wenn ich das recht verstehe). D.h. per Kommandozeile "--config=dir" und alles wird dort erwartet (bis auf die Plugins die das eh ignorieren und fix /etc/vdr im Quellcode stehen haben).
Zusätzlich dann jetzt halt nen "--data=dir" (oder wie auch immer) und die Plugins können neben configdirectory() noch datadirectory() (was configdirectory() liefert wenn --data-dir nicht gesetzt ist) nutzen.
argh, ist mir viel zu kompliziert! Wenn ich alle paar Jahre mal ein neues System aufsetze, dann kann und moechte ich mir Optionen wie --config einfach nicht merken muessen (liegt vlt. auch an meinem Alter :o)
VDR ist fuer mich etwas komplett losgeloestes von der 'normalen' Linux Installation. Und deshalb auch moeglichst alles separat speichern, so dass beim Wechsel/Update des OS die VDR Installation moeglichst wenig beeinflusst wird.
Ist aber zugegebenermassen auch eine Geschmacksfrage. Fuer mich hat sich das halt als sehr einfach und zuverlaessig herausgestellt...
PS: Ich muss natuerlich auch sagen, wie ich mein System betreibe: Im Moment auf einer Partition ein Ubuntu 10.04, auf der zweiten Partition gammelt noch ein Ubuntu 8.04 rum. Demnaechst wird das 8.04 mit einer 12.04 oder einem Debian ueberbuegelt. Dann wird mit dem neuen System erstmal getestet dass alles was ich habe auch funktioniert. Erst danach wird das dann mein 'default' System und die andere Partition kann wieder 2 Jahre rumgammeln. Genau dafuer habe ich meinen Setup optimiert. Kann man natuerlich auch ganz anders machen/sehen...
Wenn es "nur" ein Resourcen-Verzeichnis geben soll, das Plugins bei Bedarf nutzen können ist es recht einfach.
Wenn aber, wie in dem Yavdr Beispiel oder bei Debian, die Dateien teilweise in /etc/vdr und /var/lib/vdr liegen müssten wir uns da einigen welche Datei denn nun wohin soll. Das müsste dann im VDR-Code mit angepasst werden.
Da es hier aber verschiedene Auffassungen gibt welche Datei nun wo zu liegen hat sollten wir uns vorher einig werden. Sonst wirds vermutlich nichts damit das kls den Patch übernimmt und damit hätten die Plugins auch keine Standard-Funktion die sie nutzen können um das neue Verzeichnis abzufragen.
Moin!
...die Dateien teilweise in /etc/vdr und /var/lib/vdr liegen müssten...
Davon würde ich Abstand nehmen, denn da wird es nie eine Einigung geben. Das Thema kommt ja nicht das erste mal hoch.
Es gibt da nicht "die eine Wahrheit", sondern bei jeder Installation kann die eine Datei statisch (also /etc/vdr) sein und andere nicht und umgekehrt.
Es macht wesentlich mehr Sinn, alle Konfigurationsdateien an einem Ort zu haben.
Ein conf- und ein Resource-Verzeichnis ist mehr als ausreichend.
Lars.
Da stimme ich zu. Zudem hat kls zugesagt, einen Patch zu übernehmen, sofern dieser *ein* zusätzliches Verzeichnis implementiert.
Eine Datei, die heute noch statisch ist, kann sehr schnell dynamisch werden, wenn der VDR in Zukunft weitere Konfiguations-Optionen im OSD bekommen sollte.
Ob ein zusätzliches Resourcen-Verzeichnis in allen Fällen reicht ist natürlich ein anderes Thema, aber da haben die Plugin-Autoren auch jetzt bereits Lösungen gefunden (z.B. osdteletext, welches /var/cache nutzt). In Diskussionen bekommt man von Plugin-Autoren halt immer mal wieder als Argument, dass man das ConfigDirectory so schön einfach via API abfragen kann. Deshalb wird das mit den Resourcen vollgepackt.
...
Zudem hat kls zugesagt, einen Patch zu übernehmen, sofern dieser *ein* zusätzliches Verzeichnis implementiert.
Na ja, ich habe gesagt "Wenn's denn bei einem weiteren Directory bleibt ;-)".
Das war mehr eine Vermutung, daß es nicht bei einem Directory bleiben dürfte, als eine Zusage einen entsprechenden Patch zu übernehmen.
Aber warten wir erstmal ab. Meine Vorhersage ist eh, daß es keine brauchbare Einigung geben wird
Klaus
Meine Vorhersage ist eh, daß es keine brauchbare Einigung geben wird
Ich fürchte zumindest bei den Ressourcen (Bitmaps, Videos, mp3s) die die Plugins im Config Directory speichern gibts hier überraschend doch ne allgm. Zustimmung
Wobei hier der VDR ja einfach nur nen Verzeichnis (was er per Makefile/Kommandozeile mitgeteilt bekommt (wenn nicht gesetzt dann liefert es einfach das selbe wie ConfigDirectory())) ausliefern muss wenn es das Plugin per "RessourceDirectory(PLUGIN_NAME_I18N)" (analog zu ConfigDirectory()) abfragt.
Wenn dann der VDR zusätlich noch sein ./themes Verzeichnis dort RO erwarten würde wäre dann alles perfekt.
Zumindest so wie ich das hier lese ist es das was hier alle übereinstimmend für gut halten.
cu
ZitatMeine Vorhersage ist eh, daß es keine brauchbare Einigung geben wird
Oh, ein Optimist 
naja - war ja am Anfang schon alles gesagt eigentlich. Schön das es Nutzer der Symlinks gibt auf Debiansystemen ich hätte sie lieber weg. Ansonsten stimme ich zu 100% mit dem überein wie es in yavdr (Überraschung^^) (und Debian/Ubuntu) ist. Man kann sich aus verschiedenen Gründen an die FHS halten. Wenn man gerne "alles in einem Verzeichnis" hätte, quält man sich sicher mit diesem blöden Linux (Wo die das alles hinverteilen ... ts ts ts).
Was war die Frage/das Thema ? War da noch was offen ?
Wobei hier der VDR ja einfach nur nen Verzeichnis (was er per Makefile/Kommandozeile mitgeteilt bekommt (wenn nicht gesetzt dann liefert es einfach das selbe wie ConfigDirectory())) ausliefern muss wenn es das Plugin per "RessourceDirectory(PLUGIN_NAME_I18N)" (analog zu ConfigDirectory()) abfragt.
Wenn dann der VDR zusätlich noch sein ./themes Verzeichnis dort RO erwarten würde wäre dann alles perfekt.
Vorausgesetzt natürlich es gibt wirklich keinen Grund unter "./themes" zur Laufzeit zu schreiben. Soweit ich das aber sehe sind das allesamt Dateien, die das Theme-Plugin mitliefert und die dann zur Laufzeit nicht geschrieben werden.
Zitat
Zumindest so wie ich das hier lese ist es das was hier alle übereinstimmend für gut halten.
Sieht fast so aus. Wobei für das Problem ja eigentlich garnicht der VDR schuld ist. Steht ja auch nicht in der Doku, dass im "ConfigDirectory" irgendwelche Bitmaps abgelegt werden sollen. Es steht jedem Plugin-Autor bereits jetzt frei einen Pfad unter /usr/share dafür zu verwenden. Wenn man den Name der Variable im Makefile über die Plugins gleich hält, dann kann er auch in der Make.config überschrieben werden.
Resourcen und Config zu trennen macht auf jedem Fall Sinn. Während die Resourcen eigentlich statisch sind und in den meisten Fällen bei einem Update des Plugins via Paketmanager komplett ersetzt werden, sind echte Config-Dateien recht individuell. Während ich erstere nicht sichern muss wäre es bei letzteren schon sinnvoll ein Backup zu haben.
Ob dann diese Config-Dateien unter /etc/vdr oder unter /var/lib/vdr liegen ist zumindest mir recht egal. Kreuz und quer symlinken würde ich hier auf jedem Fall nicht. Wenn, dann würde ich, schon weil niemand garantiert, dass die verbliebenen statischen VDR-Configfiles auf ewig nicht via GUI bearbeitet weren können, alles unter /var/lib/vdr platzieren und das ganze Verzeichnis nach /etc/vdr symlinken.
Wenn man den Name der Variable im Makefile über die Plugins gleich hält, dann kann er auch in der Make.config überschrieben werden.
Am Ende gehts hier nur um ne Policy und nicht so sehr darum ne Menge Code zu produzieren, ob ne Funktion RessourceDirectory(PLUGIN_NAME_I18N) im VDR oder die Vereinbarung das das Plugin auf PLUGIN_RESSOURCE_DIR (Inhalt z.B. "/usr/share/vdr/plugins/%s", (%s wird dann durch den Inhalt von PLUGIN_NAME_I18N ersetzt) wenn nicht vorhanden dann ConfigDirectory(PLUGIN_NAME_I18N) nutzen) reagieren muss ist ja eigentlich auch egal.
cu
Mal so am Rande. Euch ist es schon klar worüber hier diskutiert wird. Man könnte gerade mal einen Verzeichnis einsparen und vielleicht noch ein Dutzend Symlinks. Ob das die Mühe Wert ist? Es ist nicht so, dass wir nicht wüssten, wo sie liegen.
Albert
Wenn ich das jetzt mit Bezug auf FHS zusammenfasse, komme ich nun auf 2 zusätzliche Verzeichnisse.
Ob nun statisch oder nicht sollte man am Vanilla-VDR festmachen, ob jetzt irgendwelche Patches, Plugins oder Webinterfaces auf die Idee kommen diese Dateien editierbar zu machen ist nicht Sache des VDRs dies zu berücksichtigen.
Folgende Verzeichnisse sehe ich jetzt:
/etc/vdr für statische Configs (z.B. diseqc.conf)
/var/lib/vdr für dynamische Configs die vom Vanilla-VDR geschrieben werden (z.B. setup.conf)
/usr/share/vdr für statische und architektur unabhängige Resourcen (z.B. Bitmaps)
Die größte Diskussion wird wohl um die ersten beiden Verzeichnisse entstehen.
Mal so am Rande. Euch ist es schon klar worüber hier diskutiert wird. Man könnte gerade mal einen Verzeichnis einsparen und vielleicht noch ein Dutzend Symlinks. Ob das die Mühe Wert ist?
Der Witz ist ja das es gar keine keine Mühe mach
Und was man davon hat? nun, es ist schon ein Unterschied ob man das Konfigurationsverzeichnis mit 3 MB Inhalt (das sind dann Sachen die man wirklich sichern will) wegzippt oder das mit 40 MB (weil da haufenweise Videos, mp3s, Fonts und Bilder drinliegen).
Klar es geht auch so, aber warum nicht mal einfach was verbessern? Einfach so mal nebenbei weils überhaupt keine Mühe macht.
cu
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
