[vdr] Re: Handling of reccmds.conf and commands.conf

[Patrick Cernko <errror@ps.uni-sb.de>]

Also sprach Tobias Grimm zu "03.05.2004 00:04" Anno Domini:
> That seems to be the right place for i.e. the timers.conf. But what 
> about the channels.conf? It can and sometimes needs to be edited by hand 
> and can also be changed by vdr. And as the reccmds/commands.conf are 
> generated on each start of vdr (in the debian package), /var/cache/vdr 
> or /tmp or /var/tmp seem to be the right place for this files to me. But 
> independently from where the files should be, all of vdr's conf files 
> should probably not be in the same directory. And thererefore I will end 
> up with patching vdr or at least symlinking all the files to one directory.
To sum up:

There are five different types of "conf"-files (in debian-vdr, but 
partly also in plain-vanilla vdr):

1. Full "static" conf files like svdrphosts.conf.
2. Full "generated" conf files like timers.conf.
3. conf files generated by scripts but static for vdr like commands.conf.
4. conf files generated by scripts _and_ generated by vdr like remote.conf.
5. conf files only modified by vdr like channels.conf.

The first class are very convenient and should be located in /etc. The 
second one should be located in /var/lib as specified by the FHS. The 
rest of the classes only appear due to the debian packageing.

The third class can be handled the same way as mozilla's chrome registry 
or the texmf.cnf in debian. By the way: why are these files generated by 
the vdr init script instead of a script "update-vdr-config" similar to 
the mozilla and texmf packages? For the fourth class, the only file I 
can think of to be in it is the mentioned remote.conf. In a non-debian 
vdr-installation, this file should reside in /var/lib as it is only 
generated and I even don't see a sence to edit the remote hex-codes by 
hand. The reason, this file is generated by the debian vdr init-script 
is, that it seperates the different remote's configs into seperate 
files, but I don't know why! Maybe consider leaving it fully generated 
in /var/lib as it is instead of splitting it up after generation.

Now we can come to the last type of files: conf files which must exist 
but are modified by vdr. Correct me if I'm wrong but I think the 
following files are in this class:

1. channels.conf: As vdr does not have a full-featured "channel-search" 
build in, the file must be provided with some basic channels (for 
vdr-1.2.x all channels you want, for vdr-1.3.x one channel from every 
transponder you want). I think the best way to solve the problem with 
this file is, to add a full-featured "channel-search" to vdr and to have 
vdr scan for channels upon first start (after he has leard the remote of 
course :-) ). This is the way, the enigma-software for the 
(Linux-)D-Box2 does it. This fully-generated file can then reside under 
/var/lib and everybody is free to edit it by hand if he really wants!

2. ca.conf & diseqc.conf: Both files are only needed for special 
purposes (not everyone uses CA-Modules or has DVB-s cards). 
Additionally, they do not contain very much information, mostly they are 
used "as-is" (I think). So, my propose would be, to have the information 
of theses files "build-into" vdr and vdr generates them if someone 
changes these defaults in the setup (or on first start).

3. setup.conf: This file only differs from 2. that it's information is 
_required_ for _every_ vdr installation. But the rest of my arguments of 
2. applies similar to it.


Please tell me what you think of my ideas?

@klaus: I hope you can give me also a statement about it!

CU/all
--
Patrick Cernko | mailto:errror@errror.de | http://www.errror.de
Quote of the Week: "printk("VFS: Busy inodes after unmount. "
                           "Self-destruct in 5 seconds. "
                           "Have a nice day...\n");"
                   (2.3.99-pre8 /usr/src/linux/fs/super.c)

Attachment: signature.asc
Description: OpenPGP digital signature