Gero wrote:
Vdr's databases reside in /var/lib/vdr where they are changeable by intention.
The databases are linked to /etc.
So the content from /etc (the links to vdr-databases) is static, but the
content of the databases is not.
Its not that good as if the vdr would have divided the setup into static and
non-static configuration, but it obeys the rules.
See http://wiki.debian.org/ReadonlyRoot for advantages of that aproach.
It's useless to separate between static and non-static configuration files in
VDR, as in my opinion, VDR doesn't really have files that should be static.
For example the file "diseqc.conf" should be editable via OSD, in my opinion. If
I pre-setup an VDR system for someone, then it should be possible to just hand
over the system to him and he should be able to just connect the wires and do
anything, still required, using his remote control.
So for me it seems to be useless to try to strictly separate VDR's configuration
files between "static" and "dynamic". They all should be dynamic and maybe at
any time they could get dynamic, if Klaus improves the OSD setup possibilities.
Just place them all to /var/lib/vdr and you are done.
Lots of VDR-users use VDR as a standalone system and for those systems
/var/spool might be more appropriate than /srv
/var/spool is definitively wrong, as this applies to "queue-like" things.
/srv is right, if the VDR-machine offers the recordings like a NAS or
MediaServer,
FHS says:
| /srv : Data for services provided by this system
So as VDR is the primary service of such a box, /srv seems to be OK for me. And
many distributions share the recordings via FTP or Samba anyways.
For me the discussion about the default setting seems to be useless. The current
default seems to match the FHS definitions pretty well and any distribution is
able to easily add own settings via make parameters or via Make.config. So feel
free to override the default and use your own settings.
The main topic in this "sub-thread" is testing the new patch, which will add API
functions for the plugins for the first time, allowing plugins to place their
resources to wherever the distributor decided to put them. No longer abuse of
"ConfigDirectory" for static resources! No more plugin patching! No more ugly
symlinks between /var/lib/vdr/... and /usr/share/vdr/...!
Yours
Manuel
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
