Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] Re: Handling of reccmds.conf and commands.conf
Patrick Cernko wrote:
> 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!
Well, in my own VDR all of the *.conf files are in the /video directory
and that's it. I'm not making a philosophy out of where all the files
should or should not go. I find it easy, simple and convenient to have
everything in /video.
Since every distributor probably has his own idea about where which
config files should go, I guess I'll stay out of this discussion. To
me the most important thing is that it works ;-)
To unsubscribe send a mail to email@example.com with "unsubscribe vdr" as subject.
Main Index |