Re: [vdr] Documentation and thoughts on ARGSDIR (first draft)

2015-02-18 Thread Lars Hanisch
Hi,

 There has been some progress around vdrctl.

Am 08.02.2015 um 15:05 schrieb Lars Hanisch:
[...]
 vdrctl
 --
 
 What I like to see in the future is a tool vdrctl which will add/remove 
 those symlinks or list the available or
 actived plugins etc. I would like to only specify an API for this tool, so 
 every distribution can develop its own tool.
 Of course there can be a reference implementation like a simple shell-, Perl- 
 or Python-script.
 
 In the following ARGSDIR is the configured conf.d path in your Make.config 
 (or read by pkg-config).
 AVAILDIR is ARGSDIR/../conf.avail if not another directory is given.
 Filenames are the names of the files without their directory.
 
 Usage:
   vdrctl [global options] command [command options]
 
 Global options:
   --argsdir=directory
 read files from directory instead of ARGSDIR
   --availdir=directory
 read files from directory instead of ARGSDIR/../conf.avail
 
 Commands:
 
 list
   (without options)
   print a sorted list of all configuration files from AVAILDIR
 
   --enabled
   print a sorted list of all configuration files from ARGSDIR
 
   --disabled
   print a sorted list of all configuration files from AVAILDIR which are not 
 symlinked to ARGSDIR
 
 enable filename
   create a symlink in ARGSDIR pointing to the file in AVAILDIR
 
 disable filename
   remove the symlink in ARGSDIR
 
 edit filename
   start an editor so the user can add/remove options to the file in AVAILDIR

Added a new command:

 status
   print a list of all available configuration files and if it's enabled 
(symlinked),
   disabled (no symlink in ARGSDIR) or static (regular file in ARGSDIR).

 A reference implementation has been started on github:

  https://github.com/CReimer/vdrctl

 For the next vdr developer release I will send a patch so it will possible to 
print the commandline help of a single
plugin instead of having the help of vdr and the given plugin. And maybe the 
help will have a (selectable) custom
format, so it can be directly used in a conf-file. In the extended_edit-branch 
this help is embedded into the conf-file
when invoking vdrctl edit (and is removed before saving it, just like git or 
mercurial are doing it with commit messages).

 A kind of useful tool, if you have made the work and split all the parameters 
across some files.

Stay tuned...

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Documentation and thoughts on ARGSDIR (first draft)

2015-02-18 Thread Lars Hanisch
Am 18.02.2015 um 22:17 schrieb Tobi:
 Just a quick thumbs for the whole ARGSDIR feature!
 
 Most likely I'll start migrating the Debian VDR package to this with the
 2.2.0 release.

 Great news! I'm looking forward to it!

Lars.

 
 Tobias
 
 ___
 vdr mailing list
 vdr@linuxtv.org
 http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
 


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Documentation and thoughts on ARGSDIR (first draft)

2015-02-18 Thread Tobi
Just a quick thumbs for the whole ARGSDIR feature!

Most likely I'll start migrating the Debian VDR package to this with the
2.2.0 release.

Tobias

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[vdr] Documentation and thoughts on ARGSDIR (first draft)

2015-02-08 Thread Lars Hanisch
Hi,

 I wrote down the thoughts I had in mind when developing the conf.d patch which 
got integrated in vdr 2.1.7.

 Also I like to give some advice to distributors how I think, this feature 
should be used. If we can agree on a
consistent naming and file-layout all users can profit.

 At the end there's an RFC for an interface to a not-yet-written tool vdrctl 
for managing the args-conf-files.

 Any comments and improvements are welcome.

Regards,
Lars.


Using ARGSDIR
-

The target of the conf.d patch is to simplify the start of vdr esp. with the 
newer init systems Upstart and systemd.
These systems expect a single exec line to start a daemon. Additionally they 
provide mechanism for monitoring, restart
on failure and controlled stopping on shutdown with defined dependencies.

In the past vdr needed a long list of options, every plugin had to be 
mentioned, and if a plugin also needs options, the
commandline gets longer and confusing. There's also the runvdr template for 
controlling the start and restart of vdr,
which has to be adjusted to your personally needs, which makes it difficult for 
distributions to update these script.
That is why the different distributions developed their own starting mechanisms 
and reading options for vdr and plugins
from different files. Now with all options separated from the starting script, 
it will be easier to share the same
configuration on different platforms and improve helping each other in adding 
the right options to your vdr installation.

By default, the conf-files are located at /etc/vdr/conf.d, of course this can 
be changed via the Make.config, but not on
the commandline itself, because a vdr with an option won't read the options 
from the conf-files to maintain backwards
compatibility, so you can't choose a directory on demand. But what you can do, 
is to symlink different files to your
conf.d-directory or even symlink the whole directory, to adjust your 
configuration. Additionally the directory can be
retrieved by using pkg-config --variable=argsdir vdr.

To check the current configuration the vdr would use if you start it right now, 
you can call vdr --showargs.

Here's an example from my installation:

  $ vdr --showargs
  --video=/srv/vdr/video.00
  --config=/var/lib/vdr
  --lib=/usr/lib/vdr/plugins
  --record=/usr/lib/vdr/vdr-recordingaction
  --shutdown=/usr/lib/vdr/vdr-shutdown.wrapper
  --epgfile=/var/cache/vdr/epg.data
  --user=vdr
  --grab=/tmp
  --port=6419
  --resdir=/usr/share/vdr
  --cachedir=/var/cache/vdr
  --dirnames=,,1
  --watchdog=0
  --userdump
  --plugin=epg2vdr
  --plugin=channellists
  --plugin=sundtek
  --plugin=avahi4vdr
  --plugin=dbus2vdr --shutdown-hooks=/usr/share/vdr/shutdown-hooks
--shutdown-hooks-wrapper=/usr/share/vdr-plugin-dbus2vdr/shutdown-wrapper 
--upstart
  --plugin=epgsearch -f /usr/bin/svdrpsend
  --plugin=live --port=8008 --ip=0.0.0.0 --log=INFO 
--epgimages=/var/cache/vdr/epgimages
  --plugin=menuorg
  --plugin=vnsiserver -t 10
  --plugin=streamdev-server
  --plugin=softhddevice -D
  --plugin=epgsearchonly
  --plugin=recsearch
  --plugin=restfulapi --port=8002 --ip=0.0.0.0 
--epgimages=/var/cache/vdr/epgimages
--channellogos=/usr/share/vdr-channellogos 
--webapp=/var/lib/vdr/plugins/restfulapi/webapp
  --plugin=quickepgsearch
  --plugin=conflictcheckonly
  --plugin=skindesigner --epgimages=/var/cache/vdr/epgimages
  --plugin=dynamite

The corresponding conf file looks like:

 /etc/vdr/conf.d/vdr.conf
[vdr]
--video=/srv/vdr/video.00
--config=/var/lib/vdr
--lib=/usr/lib/vdr/plugins
--record=/usr/lib/vdr/vdr-recordingaction
--shutdown=/usr/lib/vdr/vdr-shutdown.wrapper
--epgfile=/var/cache/vdr/epg.data
--user=vdr
--grab=/tmp
--port=6419
--resdir=/usr/share/vdr
--cachedir=/var/cache/vdr
--dirnames=,,1
--watchdog=0
--userdump

[epg2vdr]

[channellists]

[sundtek]

[avahi4vdr]

[dbus2vdr]
--shutdown-hooks=/usr/share/vdr/shutdown-hooks
--shutdown-hooks-wrapper=/usr/share/vdr-plugin-dbus2vdr/shutdown-wrapper
--upstart

[epgsearch]
-f /usr/bin/svdrpsend

[live]
--port=8008
--ip=0.0.0.0
--log=INFO
--epgimages=/var/cache/vdr/epgimages

[menuorg]

[vnsiserver]
-t 10

[streamdev-server]

[softhddevice]
-D

[epgsearchonly]

[recsearch]

[restfulapi]
--port=8002
--ip=0.0.0.0
--epgimages=/var/cache/vdr/epgimages
--channellogos=/usr/share/vdr-channellogos
--webapp=/var/lib/vdr/plugins/restfulapi/webapp

[quickepgsearch]

[conflictcheckonly]

[skindesigner]
--epgimages=/var/cache/vdr/epgimages

[dynamite]
 end of /etc/vdr/conf.d/vdr.conf

showargs takes as an optional parameter a directory. It will read all *.conf 
files from the given directory and prints
the corresponding configuration. This is helpful if you have various 
configurations and want to compare them.

Distributors


In the example above I use a single conf file. For a self maintained 
installation this may be usable, but from the
perspective of a distributor the configuration should be splitted into one file 
per plugin and a file