Diskussion zu Gentoo.org Ebuilds von vdr

Hallo

Zitat

- Ein RC script fü die DVB Treiber wird es nicht mehr geben! Diese sollten über modules.autoload geladen werden da sie nicht wirklich ein Dienst sind (ausserdem geht das schneller da modules sehr früh geladen wird)

- Ein reload der DVB Module mittels vdr rc script?

Finde ich auch. Ist eigentlich auch der richtige Ort für das Laden der Module. Gut wäre das automatische Einfügen der Module durch das Ebuild, wo wir wieder da wären , wie man die unterschiedlichen Kernel-Configs ausließt. Aber ist sicherlich auch irgendwie machbar.
Reload entweder über vdr-rc Scrupt oder evtl über watchdog.sh Script, wenn das möglich ist und überhaupt so bleiben soll.

Zitat

- Es wird nur noch eine Version geben (keine Trennung in vanilla/wo)!

Da kommen da aber die ganzen Patching-Geschichten mit rein, oder? Auf Basis Vanilla macht logischerweise keinen Sinn.

Zitat

- Im Moment werden die Plugin-Filenames so zusammengebaut:
"libvdr-PLUGIN.so.VDRVERSION", dies bedeutet aber das alle Plugins nach einem Update von vdr neu emerged werden müssen obwohl sie auch so laufen würden. Mein Vorschlag ist das VDR "libvdr-PLUGIN.so" läd (funzt, hab ich getestet). Bei der Installation eines Plugins ist der Filename "libvdr-PLUGIN.so.PLUGINVERSION" und es wird (wie bei libs) ein symlink erzeugt. Also z.B.
"libvdr-mp3.so.0.7.13" mit symlink "libvdr-mp3.so".

Das finde ich gut mit den Symlinks. Wenn das so funzt, soltte das so werden. Im /usr/lib siehts ja genau so aus (mehr Symlinks als Libs)

Zitat

- Std. Verzeichnis für Plugins /usr/lib oder /usr/lib/vdr?

Persönliche Meinung: /usr/lib/vdr
Ein Projkt dieser Art verdient ein eigenes Dir.

Zitat

- Die Defaultwerte für configdir, libdir als patch oder per sed ändern?

Geschmackssache, ich wäre für sed (bringt weniger files im $FILESDIR) (aber auch nur persönliche Meinung )

Zitat

- Sollen die Beispielplugins installiert werden?

Der autopid-patch bringt ja sozusagen ein plugin mit sich. Ich denke mal wir sollten das mitinstallieren. Man muß es ja nicht mit starten.

Zitat

- Wird vdr als root oder user (vdr) gestartet werden. Welche UserID und Group (video::27) ?
Welches Homedir für vdr user (/video) ?

Ich wäre für root. Falls aber doch ein vdr-user angelegt werden soll, wäre ich für ein Std-Home-Dir. Nur wegen der Ordnung.

Zitat

- modules-autoload gleich anpassen (ein oder auskommentiert) oder nur Hinweistext auf modules.autoload?

siehe oben.

Zitat

- Einbinden von Umgebungsvariablen wie jetzt per EXPORT im Configfile (vdr.dvd, vdr.mp3) und "source" im init Script oder mittels extra ConfigFile (vdr.dvd.env, vdr.mp3.env)?

Ich fiinde, über source im init-script funzt gut und kann man so lassen. Allerdings verstehe ich die ander Möglichkeit nicht ganz. Kannst du das mal kurz erklären? Danke.

Zitat

- Steuerung des Ebuilds mittels VDR_OPTS oder USE?
USE Nachteil: Fluten mit VDR USE Variablen
VDR_OPTS Nachteil: alle Sourcen werden immer geladen, extra Logic im Ebuild nötig

Hmmm. Da muß ich passen wegen der vdr_opts Geschichte. Ist nicht so mein Ding mit Scripterei. Aber wenn es mit nicht zuviel Aufwand so funzen würde wäre ich für getrennte Variablen für die Patches und die Plugins. Also schon Plugins beim emergen des VDR mit anzugeben. Aber wie gesagt... das wird wahrscheinlich ziehmlich aufwendig das ebuild. Ich stelle mir das so vor:

VDR_OPTS="lirc elchie vfat" VDR_PLUGINS="dvd mp3" emerge vdr

Wird aber wahrscheinlich zu fett von der Logik her.

Zitat

PLugin-Ebuilds als "vdr-mp3" oder "vdrplugin-mp3" oder??

vdrplugin-mp3 finde ich aussagekräftiger !

Zitat

- dvd Plugin braucht eine gepatchte libdvdnav! Soll die als extra Ebuild installiert werden oder zusammen mit dem dvd Plugin kompiliert und dann statisch gelinkt werden?

Da finde ich auch eine Installation zusammen mit dem DVD-Plugin sinnvoll. Ein Extra-Ebuild , wie es jetzt ist, wäre unnötig.

Danke für das anregende Posting mad.
Martini

Zitat

Original von mad
- Ein RC script fü die DVB Treiber wird es nicht mehr geben! Diese sollten über modules.autoload geladen werden da sie nicht wirklich ein Dienst sind (ausserdem geht das schneller da modules sehr früh geladen wird)

wieso nicht gleich in /etc/modules.d/dvb + modules-update?

Zitat

- Es wird nur noch eine Version geben (keine Trennung in vanilla/wo)!

Ich finde es macht eh nur richtig Sinn eine stable reinzupacken (1.2)

Zitat

- Im Moment werden die Plugin-Filenames so zusammengebaut:
"libvdr-PLUGIN.so.VDRVERSION", dies bedeutet aber das alle Plugins nach einem Update von vdr neu emerged werden müssen obwohl sie auch so laufen würden. Mein Vorschlag ist das VDR "libvdr-PLUGIN.so" läd (funzt, hab ich getestet). Bei der Installation eines Plugins ist der Filename "libvdr-PLUGIN.so.PLUGINVERSION" und es wird (wie bei libs) ein symlink erzeugt. Also z.B.
"libvdr-mp3.so.0.7.13" mit symlink "libvdr-mp3.so".

Schöne Lösung!

Zitat

- Std. Verzeichnis für Plugins /usr/lib oder /usr/lib/vdr?

/usr/lib/vdr finde ich übersichtlicher. Wobei es eigentlich gar nicht so viele Plugins sind.

Zitat

- Soll ein shutdownscript mitgeliefert werden?

Wieso nicht?

Zitat

- Sollen die Beispielplugins installiert werden?

Ich finde die gehöhren zu VDR dazu. Auch wenn sie kaum einer nutzt.

Zitat

- Wird vdr als root oder user (vdr) gestartet werden. Welche UserID und Group (video::27) ?
Welches Homedir für vdr user (/video) ?

Finde eigenen user (vdr) besser. Irgenwie ist das für Linux peinlich wenn es als root laufen muss. Obwohls auch bei mir so ist

Zitat

- modules-autoload gleich anpassen (ein oder auskommentiert) oder nur Hinweistext auf modules.autoload?

s.o.

Zitat

- Steuerung des Ebuilds mittels VDR_OPTS oder USE?
USE Nachteil: Fluten mit VDR USE Variablen
VDR_OPTS Nachteil: alle Sourcen werden immer geladen, extra Logic im Ebuild nötig

Finde VDR_OPTS die schönere Variante.

Zitat

- Die API und Plugin Doku nur installieren wenn Angegeben. (gibts ein extra Flag für??).

Ich würde es gleich nach /usr/share/doc/vdr packen

Zitat

- PLugin-Ebuilds als "vdr-mp3" oder "vdrplugin-mp3" oder??

Ersteres.

Zitat

- dvd Plugin braucht eine gepatchte libdvdnav! Soll die als extra Ebuild installiert werden oder zusammen mit dem dvd Plugin kompiliert und dann statisch gelinkt werden?

Braucht es das überhaupt noch? Ich glaube mich zu erinnern das es auch ohne geht, obwohl es noch im README steht.

Steffen

Hi,
soviele Fragen ??!!

Also wenn das in den offiziellen Potagebau aufgenommen werden soll , dann muß man
es erstmal auf den kleinsten Nenner bringen.

Also KB Steuerung und wer LIRC ,etc. will, dann
über USES.
Dann , automatisch in modules.autoload eintragen
ist wohl auch nicht gestattet. Ist auch gut so :D.
Schutz des Systems hat Vorrang vor Bequemlichkeit.

/usr/lib/vdr finde ich auch besser. Habe alle Plugins
dorthin geschoben.

Beispielplugins , ja . Gehören halt dazu (auch wenn kaum jemand sie nutzt).

VDR als user und nicht als root.

Doku nach /usr/share/doc/vdr
Als erstes gleich ein Howto /Faq .oä. dorthin schieben.
Vor allen anderem.
Dann würde ich nicht soviel nachprüfen bzw. Infos ausgeben sondern dorthin verweisen.
Wo dann auch die Kerneleinstellung Abhängigkeiten ,
etc. erklärt wird.
Z.B.: depend vdr-doku o.ä (auch vor den Treibern).

Ich meine jeder hier weiß was ihn erwartet und findet sich zurecht.
Aber es muß auch möglich sein für einen Taiwanesen o.ä der noch nie was mit VDR zu tun gehabt hat,
vdr emergen zu können ohne Grundwissen
wo er was einzutragen hat.
Abgesehen von uses ,etc...

bye

Zitat

- Ein RC script fü die DVB Treiber wird es nicht mehr geben! Diese sollten über modules.autoload geladen werden da sie nicht wirklich ein Dienst sind (ausserdem geht das schneller da modules sehr früh geladen wird)
- Ein reload der DVB Module mittels vdr rc script?

finde ich vernünftig, s.u.

Zitat

.....
Also z.B. "libvdr-mp3.so.0.7.13" mit symlink "libvdr-mp3.so".

hört sich gut an

Zitat

- Std. Verzeichnis für Plugins /usr/lib oder /usr/lib/vdr?

der Übersichtlichkeit halber, und da vdr eine gewisse Größe hat, lieber /usr/lib/vdr

Zitat

- Configurationsverzeichnis /etc/vdr trotz Schreibzugriff auf einigen Files?

ich weiß es auch nicht;-)

Zitat

- Soll ein shutdownscript mitgeliefert werden?

Ich denke da an ein Template in /usr/share/doc/vdr, das sich jeder selbst anpassen und z.B. unter /usr/local/bin/vdr (oder besser /usr/local/lib vdr?) installieren kann.
Denke mal, das lässt sich nur schwer auf einen gemeinsamen Nenner bringen. Nicht jeder benutzt nvram-wakeup, das ja auch nicht mitinstalliert wird. Und wenn der vdr als eigener User läuft, empfiehlt sich sudo für den Zweck. Das könnte man dann händich, evtl. gemäß kurzer Anleitung, installieren, zumal sich da bei Updates seltenst was dran ändern dürft.

Zitat

- Die Defaultwerte für configdir, libdir als patch oder per sed ändern?

sed klingt universeller

Zitat

- Sollen die Beispielplugins installiert werden?

gehören imo dazu

Zitat

- Wird vdr als root oder user (vdr) gestartet werden. Welche UserID und Group (video::27) ?
Welches Homedir für vdr user (/video) ?

vdr, hauptsächlich wegen der Sicherheit.

einige daemons haben uids/gids im 2xxer-Bereich...

Eine eigene vdr-Gruppe gefällt mir besser. Hört sich flexibler an, und ein user vdr kann auch in dieser Gruppe laufen. Habe selbst ein eigenes /home/vdr, in dem nochmal so ein paar Sachen installiert/konfiguriert sind, die nur den user vdr betreffen (z.B. für wine und vnc). Als default homedir finde ich allerdings $VIDEO ganz angebracht (Henne-Ei-Problem bei Erstinstallation)
Die devices an sich sollten, der Kompatiblität mit anderen Anwendungen wegen, besser als root.video laufen. So ist das auch bei v4l gemacht. User vdr braucht dann video als "supplementary group".

Zitat

- devfsd Konfigfile installieren und gleich einbinden?

Im Treiberpaket meinst du? Mir fällt nichts ein, was dagegen spricht.
Mein Vorschlag:
/etc/conf.d/dvb:
REGISTER ^dvb$ PERMISSIONS root.root 0755
REGISTER ^dvb/adapter[0-9]$ PERMISSIONS root.root 0755
REGISTER ^dvb/adapter[0-9]/.*$ PERMISSIONS root.video 0660

Zitat

- modules-autoload gleich anpassen (ein oder auskommentiert) oder nur Hinweistext auf modules.autoload?

tja - so ganz durchgeblickt habe ich da nie, aber kann man das nicht in /etc/modules.d/dvb derart einbinden, dass sich die Module bei Bedarf selbst laden? Wenn man da ein wenig Hand anlegen müsste, gemäß HInweisen in /usr/share/doc/vdr/, fände ich das nicht schlimm.
Dann müsste sich das vdr startscript im Falle eines Falles nur um das Entladen kümmern - evtl. nur bei einem expliziten "reload". "vdr stop" sollte besser nicht die Treiber entladen.

Zitat

- Einbinden von Umgebungsvariablen wie jetzt per EXPORT im Configfile (vdr.dvd, vdr.mp3) und "source" im init Script oder mittels extra ConfigFile (vdr.dvd.env, vdr.mp3.env)?

So 100pro verstehe ich die zweite Möglichkeit auch nicht. Mit der ersten meinst du diese automatische Einbindung von (sinngemäß) /etc/conf.d/$INITSCRIPTNAME? Finde ich gut so.

Zitat

- Steuerung des Ebuilds mittels VDR_OPTS oder USE?
USE Nachteil: Fluten mit VDR USE Variablen
VDR_OPTS Nachteil: alle Sourcen werden immer geladen, extra Logic im Ebuild nötig

Da habe ich mich nicht sonderlich mit beschäftigt, nur mal ein paar Gedanken, basierend auf deinen Ausführungen: ne Unzahl von USEs hört sich nicht gut an und ist störend, wenn man die Gesamtliste der USE-Variablen mal reinziehen will. Falls das mit der logic halbwegs machbar ist (und nicht zu Eskapaden bei Updates führt): Wenn alle Source immer geladen werden (was auch immer genau das heißen soll;-)), - und der Build dabei etwas länger dauert, aber sonst nichts besonderes passiert, sollte das nicht weiter stören. Falls etc-update dann aber ne ganze Menge mehr neue Configfiles rausschmeißt, so wäre das weniger gut.

Zitat

- Die API und Plugin Doku nur installieren wenn Angegeben. (gibts ein extra Flag für??).

Da der vdr ja meistens was "zentrales" in der Installation ist, fände ich es vertretbar, direkt alles zu installieren. Die Doku ist ja auch nicht sonderlich groß.
Ansonsten würde ich die schon vorhandene USE "doc" dafür nehmen - ist für "extra documentation" gedacht

Zitat

- PLugin-Ebuilds als "vdr-mp3" oder "vdrplugin-mp3" oder??

vdrplugin-mp3 ist aussagekräftiger und lässt Spielraum für solche Sachen, die kein Plugin sind

ps: ich habe für das wiki in Sachen vdr user zwar schon n paar Sachen vorbereitet, aber in Anbetracht der Diskussion stelle ich das erst mal hinten an;-).

grüße

metrio

Zitat

dvb treiber über modules.autoload

Ich finde nach wie vor /etc/modules.d/dvb + modules-update besser. Was spricht dagegen?

Zitat

Kommentare? Dann werd ich diese woche mal den nackten vdr und die dvb treiber updaten und hoffe auf rege tests. werd die ebuild hier ankündigen.

Dann werde ich mit der 1.2 warten bis das ebuild fertig ist, obwohl es in den Fingern kribbelt

Steffen

Hi

..ich bin auch schon gespannt. Mein VDR läuft immernoch auf 31. :D:D:D Hab lange nix mehr dran gemacht. Die Sache mit den Modules ist Geschmackssache, sage ich mal. Gibt halt viele Möglichkeiten. Sehen wir mal, ändern kann man das ja immernoch.

Danke mad

Martini

Hi,

das Thema mit den Modulen beschäftigt mich ja auch schon länger. Formal ist die modules.autoload ein guter Weg denke ich. (Auch wenn ich darüber nicht unbedingt begeistert bin). Aber leben kann ich damit, wenn es einen einfachen Weg gibt, die Module bei Bedarf zu entladen und neu zu laden.
In der Praxis laufen die DVB Treiber eben nur zu 99% stabil und ein reboot steht ja wohl nicht zur Diskussion.

Habt ihr euch bezüglich der verschiedensten Patche mal die Version mega-super-all-in-one Lösung bei http://www.akool.de/download.html angesehen.
Habe gestern mal eben einen 1.2.0 damit gebaut. Ist noch nicht komplett getestet, scheint soweit aber sogar mit weiteren zusätzlichen Patches zu laufen.

Gruß Henning

Hi

Jo, die Patches sind auch wirklich immer aktuell. AKool macht sich echt ständig die Mühe, wenn etwas neues rausgekommen ist, seine Patches sofort zu aktualiesieren. Geht rasant schnell bei ihm. Das würde den Aufwand mit den einzelnen Patches in den ebuilds gewaltig reduzieren. Vorallem die Kombinantion der verschiedenen Sachen muß ja vorher immer gecheckt werden und wenn nötig neue Kombi-Patches gebaut werden. Ich glaube die 2 die er breitstellt, sind eine gute Alternative fürs erste. Einmal der mit AIO für Leute ohne DXR3 und bei Usern mit DXR3 halt den anderen ohne Elchi.

Martini

Hi,

also im Prinzip sind wir uns doch einig wegen der Module.
Das Argument des schnelleren Ladens ist für mich ziemlich uninteressant. Bei mir läuft der VDR nämlich auf dem Server in meiner Bastelecke. Und der ist normalerweise sowieso mindestens 18 Stunden am Tag in Betrieb, wenn er nicht sogar durchläuft.
Habe nur 3m RGB und IR Leitungen bis zum Fernseher :D.

Bezüglich der Patche, sollten wir erst mal mad's neues Standard vdr-ebuild abwarten und dann darauf aufbauen.

Gruß Henning

Hi

Jepp, *zustimm* , modules.autoload ist OK. Unter wegen Patches auch *zustimm* :D:D

Martini

Ziehe meinen Vorschlag zurück. Hatte das was falsch verstanden
modules.autoload ist der richtige Platz.

Steffen