Hi Mailinglist,
could someone please review the attached patch? It's originally posted by Maniac in this thread --> http://www.vdr-portal.de/board60-linux/board14-betriebssystem/p1054966-vdr-v...
The documentation and some Makefile changes are my work. The main code changes are Maniac's work.
I hope the code as well as the documentation is ok, so that the patch can be added in the next VDR Version.
Thanks,
Christopher Reimer
Hi,
On Friday 06 April 2012 - 15:01:14, Christopher Reimer wrote:
I hope the code as well as the documentation is ok, so that the patch can be added in the next VDR Version.
The comment (line 8ff) was a good joke on forum discussion thread, but keeping it that way sounds really offending to me. I don't think, its a good choice.
kind regards
Gero
On 06.04.2012 17:06, Gero wrote:
Hi,
On Friday 06 April 2012 - 15:01:14, Christopher Reimer wrote:
I hope the code as well as the documentation is ok, so that the patch can be added in the next VDR Version.
The comment (line 8ff) was a good joke on forum discussion thread, but keeping it that way sounds really offending to me. I don't think, its a good choice.
But isn't that exactly what happens then? ;-) The files *are* spread all over the place. Besides, who reads the INSTALL file, anyway... ;-)
Klaus
I think there's one problem left.
Doesn't VDR try to create the "plugins" subdir?
VDR runs usually as user. Most distribution maintainer will give VDR write permission for the cache dir and the config dir. But not for the resource dir.
To prevent these permission problems I think it's neccessary to change the Makefile from
install-dirs: @mkdir -p $(DESTDIR)$(VIDEODIR) @mkdir -p $(DESTDIR)$(CONFDIR) @mkdir -p $(DESTDIR)$(RESDIR) @mkdir -p $(DESTDIR)$(CACHEDIR)
to
install-dirs: @mkdir -p $(DESTDIR)$(VIDEODIR) @mkdir -p $(DESTDIR)$(CONFDIR)/plugins @mkdir -p $(DESTDIR)$(RESDIR)/plugins @mkdir -p $(DESTDIR)$(CACHEDIR)/plugins
or at least
install-dirs: @mkdir -p $(DESTDIR)$(VIDEODIR) @mkdir -p $(DESTDIR)$(CONFDIR) @mkdir -p $(DESTDIR)$(RESDIR)/plugins @mkdir -p $(DESTDIR)$(CACHEDIR)
On Friday 06 April 2012 - 18:07:55, Klaus Schmidinger wrote:
On 06.04.2012 17:06, Gero wrote:
The comment (line 8ff) was a good joke on forum discussion thread, but keeping it that way sounds really offending to me. I don't think, its a good choice.
But isn't that exactly what happens then? ;-) The files *are* spread all over the place. Besides, who reads the INSTALL file, anyway... ;-)
Well, *I* think, that there's a big difference between keeping things in order compared to spreading things all over the place.
The one who eats where he shits, surely has a single place for his *IO* - but I neither consider this habit as recommended, nor exemplary. ... but well - after all its just my opinion.
kind regards
Gero
On Fri, Apr 6, 2012 at 11:25 AM, Gero geronimo013@gmx.de wrote:
Well, *I* think, that there's a big difference between keeping things in order compared to spreading things all over the place.
I can't stand when things are installed all over the place. It's too messy and pointless in my opinion. I'm in the habit of simply running VDR from it's source dir and using symlinks. It makes things very easy like archiving working/test sources, changing between versions without any needless 'reinstall'ing, etc. I see no benefit what-so-ever to installing over running VDR from the source dir, unless of course you're using pre-compiled binaries.
As far as the patch, is it really necessary to split the files up even further? What is the real benefit? Also, don't different distros use different dir structures, so what's common on some may not be on others? If this is an attempt to standardize something, it's probably best to find a standard that exists across _all_ distros (if this isn't the case here).
On Saturday 07 April 2012 - 04:05:16, VDR User wrote:
I can't stand when things are installed all over the place.
Let's take a quick look at real life: if you need to exchange the tooth belt on your motorcycle - will you perform that task in your living room?
if you visit your friend for the first time and you look for a cold beer - will you look in his bedroom?
In real life we all "spread our things all over the house" to keep them in order. The refrigerator will be placed in the kitchen, the car in the garage and your bed will most probably be in your bedroom.
If you like to sleep on toilet or shit in your kitchen - I don't mind. For me, people that like to keep their PC in order behave quite natural, there's no need to offend them for thinking different.
kind regards
Gero
In real life we all "spread our things all over the house" to keep them in order.
Exactly. And the point of spreading files all over the directory tree (not filesystem) is to be able to easily:
- split the tree into several filesystems that have different properties such as size, speed, availability when the network is up, etc. - make part of the tree read only (to protect it from some problems) - make part of the tree shared between computers - and some parts shared between computers of different cpu architectures
For example it should be possible to make /usr read only and share /usr/share between different cpu architectures.
On Fri, Apr 6, 2012 at 9:50 PM, Gero geronimo013@gmx.de wrote:
I can't stand when things are installed all over the place.
Let's take a quick look at real life: if you need to exchange the tooth belt on your motorcycle - will you perform that task in your living room?
if you visit your friend for the first time and you look for a cold beer - will you look in his bedroom?
In real life we all "spread our things all over the house" to keep them in order. The refrigerator will be placed in the kitchen, the car in the garage and your bed will most probably be in your bedroom.
I don't spread things all over my house and from the sound of it neither do you(?). All my bathroom items are in the bathroom. All my kitchen items are in my kitchen. All my office items are in my office. I keep everything VDR in one place. It works great (for me). I see no reason to put a VDR binary in one dir, plugin binaries in another dir, config files in another dir, this stuff in this dir, that stuff in yet another dir..
If you like to sleep on toilet or shit in your kitchen - I don't mind. For me, people that like to keep their PC in order behave quite natural, there's no need to offend them for thinking different.
I'm not sure who is offended but if my personal preference & opinion offends you, maybe you shouldn't value other peoples preferences & opinions so much because it's not a big deal.
Instead of going on about that stuff, which is completely irrelevant, maybe someone can answer what I've already asked:
"As far as the patch, is it really necessary to split the files up even further? What is the real benefit? Also, don't different distros use different dir structures, so what's common on some may not be on others? If this is an attempt to standardize something, it's probably best to find a standard that exists across _all_ distros (if this isn't the case here)."
Cheers
On Saturday 07 April 2012 - 08:43:40, VDR User wrote:
I don't spread things all over my house ... All my bathroom items are in the bathroom. All my kitchen items are in my kitchen. All my office items are in my office.
But you use all that items on different tasks in different places. I guess, most of us will do.
So imagine a family with 2 parents, 6 children and all of them like the same order as above: all bathroom items in the bathroom, all kitchen items in the kitchen, ... But every person knows to distinguish its own items from the others items in the same room. There's no problem in real life.
So why don't you want allow such an order in vdr-systems? Imagine the bathroom items are the vdrs databases, the kitchen is the recording root and the office is the binary and configuration...
... if my personal preference & opinion offends you, ...
NO - it does not!
I support the freedom of every individual to live at its own taste.
I can support your different way of thinking without the need to like the way you live. And of cause without to follow your way of living.
maybe you shouldn't value other peoples preferences & opinions so much because it's not a big deal.
I don't argue about other people preferences.
May be you lost the start of discussion.
I only argued against the *comment* which I understand as kind of offending people, that like things in order. I don't mind, if you laugh about my way of living / thinking.
But putting such a comment in the INSTALL instructions, that everyone needs to read, that likes to install a vdr on its own - is not a trivial matter. Such a comment in code is no problem at all, but INSTALL or help-files or other *public* files is quite different.
In OO-terms, the INSTALL is part of the public interface and that comment is not right for the public interface. It might be ok, in the internal stuff. I laughed a lot when I first read it, but my humor may not be standard ;)
Well, that's my thoughts. I'm not known to be very polite, but I try to improve myself every day a bit further.
kind regards
Gero
[ ... arguments about pros and cons of FHS ... ]
The purpose of this thread is not to discuss the pros and cons of the FHS vs. having all files of an application in one place. Clearly these two approaches are so fundamentally different that there will never be a common ground. And any comparison to real-life behavoir apparently can always be used both ways. So let's just cut the crap here and focus on what this is really about.
Christopher Reimer has posted a patch that introduces a way of making VDR store its files according to the FHS, in case somebody wants to do that. This patch will *NOT* change VDR's default behavior of storing all files in one place. If you want to make VDR use the FHS, you need to use the respective command line options or make the proper entries in your Make.config file.
What I want to see in this thread are ACKs (or NACKs) from people who have actually reviewed the patch, and preferably have applied and tested it. Does the patch actually do what it is suppposed to do? Does it retain the default behavior of storing all files in one place? Does it break anything?
Unless I get at least three ACKs for this patch, it won't go into the official VDR source. So far, I haven't seen a single one, so the status is currently "not accepted".
As for the "offending" comment in INSTALL: it was me who insisted in this, so please don't blame it on Christopher. I just want to make it very clear to anybody who uses this feature that this will result in VDR's files being stored in many different places. VDR users have a tendency to blindly apply any patches the can find, without really considering whether this does anything useful for them ;-)
Klaus
Am 2012-04-07 04:05, schrieb VDR User:
On Fri, Apr 6, 2012 at 11:25 AM, Gerogeronimo013@gmx.de wrote:
Well, *I* think, that there's a big difference between keeping things in order compared to spreading things all over the place.
I can't stand when things are installed all over the place. It's too messy and pointless in my opinion. I'm in the habit of simply running VDR from it's source dir and using symlinks. It makes things very easy like archiving working/test sources, changing between versions without any needless 'reinstall'ing, etc. I see no benefit what-so-ever to installing over running VDR from the source dir, unless of course you're using pre-compiled binaries.
I do not think that you would do this with your entire Linux system.... ;-)
Before the file hierarchy standard, Linux was a bit messy. Nowadays one knows where to find things. Configuration for example in /etc - a no brainer. It makes life much easier, e.g. when backing up the system's configuration.
You can (guessed) most probably still start your VDR with the directories given as commandline arguments. Sure, this means some custom script for you. But the FHS helps many other people.
Kind regards, Stefan
Am 06.04.2012 15:01, schrieb Christopher Reimer:
could someone please review the attached patch? It's originally posted by Maniac in this thread -->
On the original topic, I see room for one improvement:
The defaults of the new --cachedir and --resdir parameter are the defaults set by Make.config's CACHEDIR and RESDIR. This is a minimal change in behavior to previous versions, where these were handled by --video and --config. So any old VDR that gets updated will behave different in case that --video or --config is set, and now needs to also have --cachedir and --resdir set. On the other hand, there needs to be a way for distributions to set their defaults so that VDR finds them automatically.
My suggestion: Allow to keep the default CACHEDIR and RESDIR un-set (empty), and if --cachedir or --resdir is not present, default to whatever --video and --config is actually set to. That way, the package builder can decide whether to set CACHEDIR and RESDIR or not, and if they're set, he has to make sure that the startup scripts get modified to support --cachedir and --resdir if necessary.
For an extra, an explicit --cachedir="" and --resdir="" could also override an explicit CACHEDIR and RESDIR and revert to duplicating --video and --config.
Cheers,
Udo
2012/4/7 Udo Richter udo_richter@gmx.de
Am 06.04.2012 15:01, schrieb Christopher Reimer:
could someone please review the attached patch? It's originally posted by Maniac in this thread -->
On the original topic, I see room for one improvement:
I tried to fix this on my own. So be careful
In case CACHEDIR and VIDEODIR are equal and Cachdir isn't set via command line while Videodir is set. It should now use the Videodir as Cachedir.
It is a bit confusing that there's no DEFAULTVIDEODIR in vdr.c
RESDIR and CONFDIR should work similar.
Nevertheless isn't ConfigDir also staying default, in case the VideoDir is changed via --video.
Christopher
Udo Richter wrote:
My suggestion: Allow to keep the default CACHEDIR and RESDIR un-set (empty), and if --cachedir or --resdir is not present, default to whatever --video and --config is actually set to. That way, the package builder can decide whether to set CACHEDIR and RESDIR or not, and if they're set, he has to make sure that the startup scripts get modified to support --cachedir and --resdir if necessary.
For an extra, an explicit --cachedir="" and --resdir="" could also override an explicit CACHEDIR and RESDIR and revert to duplicating --video and --config.
It is difficult to read your description (and no, I didn't understand it). How would you want to document this in a way, someone actually understands it?
If someone updates from 1.6 to an (upcoming) 2.0, then two new parameters to VDR won't be his only problem, so I vote against bloating the VDR sourcecode just to add some difficult logic on how and when directories are set by compile parameters or VDR parameters.
Yours
Manuel
Am 08.04.2012 09:48, schrieb Manuel Reimer:
It is difficult to read your description (and no, I didn't understand it). How would you want to document this in a way, someone actually understands it?
I guess I have to find a way to be more clear...
Ok, second attempt: - Makefile does not set CACHEDIR and RESDIR - Make.config *can* set CACHEDIR and RESDIR, or not. - If --cachedir or --resdir is set by command line, use them. - If not, default to CACHEDIR and RESDIR. - If CACHEDIR or RESDIR is not set (empty string), fall back to whatever --video and --config is set to.
Patched patch attached. ;) Needs documentation updated though.
Cheers,
Udo
2012/4/8 Udo Richter udo_richter@gmx.de
- If CACHEDIR or RESDIR is not set (empty string), fall back to whatever
--video and --config is set to.
No, CACHEDIR and RESDIR should work in the same behaviour as CONFDIR or VIDEODIR.
This sounds a bit like you set all your directories by command line. Sorry, but why don't you just use Make.config like everyone else does.
On Sun, Apr 8, 2012 at 10:57 AM, Christopher Reimer c.reimer1993@googlemail.com wrote:
- If CACHEDIR or RESDIR is not set (empty string), fall back to whatever
--video and --config is set to.
No, CACHEDIR and RESDIR should work in the same behaviour as CONFDIR or VIDEODIR.
This sounds a bit like you set all your directories by command line. Sorry, but why don't you just use Make.config like everyone else does.
I know several people who set their directories on the command line and ignore maintaining Make.config completely so it's not true everyone uses Make.config.
Cheers
2012/4/8 VDR User user.vdr@gmail.com
I know several people who set their directories on the command line and ignore maintaining Make.config completely so it's not true everyone uses Make.config.
OK, that could be possible, although I don't understand why.
Let's wait what Klaus says.
On Sun, Apr 8, 2012 at 2:11 PM, Christopher Reimer c.reimer1993@googlemail.com wrote:
2012/4/8 VDR User user.vdr@gmail.com
I know several people who set their directories on the command line and ignore maintaining Make.config completely so it's not true everyone uses Make.config.
OK, that could be possible, although I don't understand why.
For me personally, I set these things (and many others) in my (multi-purpose) tv script so I have most settings in one place. I prefer consolidating when possible simply because it's easier to maintain in my opinion. Any time I update VDR for example, I don't have to worry about modifying or copying an archived Make.config. I just compile the source, set my /vdr symlink to it and "tv restart".
Cheers
On 08.04.2012 23:11, Christopher Reimer wrote:
2012/4/8 VDR User <user.vdr@gmail.com mailto:user.vdr@gmail.com>
I know several people who set their directories on the command line and ignore maintaining Make.config completely so it's not true everyone uses Make.config.OK, that could be possible, although I don't understand why.
Let's wait what Klaus says.
The only condition I want to be met is that when building the original, unpatched VDR out of the box, without any user defined Make.config etc., it needs to behave just like it does now.
However, there is one thing in the current behavior that I would even consider a bug: if one starts VDR with
vdr -v /mydir
it uses /mydir as the video directory, but still uses /video for the configuration files. I believe that as long as there is no explicit -c option given, the config directory should follow what's given in the -v option. So I wouldn't mind if this was fixed along with implementing the FHS stuff ;-) (or in a separate step).
Klaus
2012/4/9 Klaus Schmidinger Klaus.Schmidinger@tvdr.de
However, there is one thing in the current behavior that I would even consider a bug: if one starts VDR with
vdr -v /mydir
it uses /mydir as the video directory, but still uses /video for the configuration files. I believe that as long as there is no explicit -c option given, the config directory should follow what's given in the -v option. So I wouldn't mind if this was fixed along with implementing the FHS stuff ;-) (or in a separate step).
Ok, maybe Udo can add this to the patch.
Udo, please also mind the additional Makefile change I mentioned before.
I can't find a special place where to add this to the documentation. In addition I think it's self explanatory
On 9.4.2012 12:54, Klaus Schmidinger wrote:
vdr -v /mydir
it uses /mydir as the video directory, but still uses /video for the configuration files. I believe that as long as there is no explicit -c option given, the config directory should follow what's given in the -v option.
Shouldn't it follow option given at ./configure?
On 09.04.2012 13:15, Pertti Kosunen wrote:
On 9.4.2012 12:54, Klaus Schmidinger wrote:
vdr -v /mydir
it uses /mydir as the video directory, but still uses /video for the configuration files. I believe that as long as there is no explicit -c option given, the config directory should follow what's given in the -v option.
Shouldn't it follow option given at ./configure?
What "./configure"???
Klaus
Am 09.04.2012 11:54, schrieb Klaus Schmidinger:
However, there is one thing in the current behavior that I would even consider a bug: if one starts VDR with
vdr -v /mydir
it uses /mydir as the video directory, but still uses /video for the configuration files. I believe that as long as there is no explicit -c option given, the config directory should follow what's given in the -v option.
You're sure about -c following -v? It worked that way until 1.5.8, but has been dropped in favor of the final changes regarding CONFDIR in 1.5.11. I don't see any reason to change that. Or did you mess up --config with --cachedir? Happened to me too.
In the latter case: In my patch, the cacheDirectory follows the VideoDirectory, even if the latter is set by --video, but only as long as CACHEDIR is un-set. (Same applies to --config and RESDIR.)
I'm not sure whether this should also be the case if VDR is compiled to be FHS compliant. In that case users should know about the various folders, and setting a --video directory should not have precedence over CACHEDIR=/var/lib/vdr. The only thing I could think of is to check whether CACHEDIR==VIDEODIR, and only then let cacheDirectory follow --video, but I would prefer to not use such hacks.
On 09.04.2012 15:18, Udo Richter wrote:
Am 09.04.2012 11:54, schrieb Klaus Schmidinger:
However, there is one thing in the current behavior that I would even consider a bug: if one starts VDR with
vdr -v /mydir
it uses /mydir as the video directory, but still uses /video for the configuration files. I believe that as long as there is no explicit -c option given, the config directory should follow what's given in the -v option.
You're sure about -c following -v? It worked that way until 1.5.8, but has been dropped in favor of the final changes regarding CONFDIR in 1.5.11. I don't see any reason to change that. Or did you mess up --config with --cachedir? Happened to me too.
I surely didn't mean --cachedir because my VDR doesn't have that option (yet) ;-). A while ago I ran a test and wanted to use a different video directory, so I started VDR with the -v option. I was surprised to see that it still loaded the config files from the default /video directory.
In the latter case: In my patch, the cacheDirectory follows the VideoDirectory, even if the latter is set by --video, but only as long as CACHEDIR is un-set. (Same applies to --config and RESDIR.)
I'm not sure whether this should also be the case if VDR is compiled to be FHS compliant. In that case users should know about the various folders, and setting a --video directory should not have precedence over CACHEDIR=/var/lib/vdr. The only thing I could think of is to check whether CACHEDIR==VIDEODIR, and only then let cacheDirectory follow --video, but I would prefer to not use such hacks.
Currently VDR has only two directories, 'video' and 'config'. The idea is that by default the video directory is /video, and the config directory is the same. If -v is given, this changes the video directory, and since config follows video (or at least is supposed to), the config files will be loaded from the new video directory. Only if there is an explicit -c option shall the config directory be different from the video directory.
I'd like to see a similar mechanism for the two new directories 'cache' and 'resource'. By default they follow 'config' and can only be different if the respective options are given. The default values for 'cache' and 'resource' shall be empty, in which case they follow 'config'. If VDR is compiled with non-empty values for 'cache' and/or 'resource', simply let them no longer follow 'config' (same behavior as if a command line option has been given).
Don't know whether the patch already behaves this way (haven't checked), but that's the way it should be.
Klaus
Hello,
what is the current status in this topic? Anyone working on this?
Yours
Manuel
Klaus Schmidinger wrote:
On 09.04.2012 15:18, Udo Richter wrote:
Am 09.04.2012 11:54, schrieb Klaus Schmidinger:
However, there is one thing in the current behavior that I would even consider a bug: if one starts VDR with
vdr -v /mydir
it uses /mydir as the video directory, but still uses /video for the configuration files. I believe that as long as there is no explicit -c option given, the config directory should follow what's given in the -v option.
You're sure about -c following -v? It worked that way until 1.5.8, but has been dropped in favor of the final changes regarding CONFDIR in 1.5.11. I don't see any reason to change that. Or did you mess up --config with --cachedir? Happened to me too.
I surely didn't mean --cachedir because my VDR doesn't have that option (yet) ;-). A while ago I ran a test and wanted to use a different video directory, so I started VDR with the -v option. I was surprised to see that it still loaded the config files from the default /video directory.
In the latter case: In my patch, the cacheDirectory follows the VideoDirectory, even if the latter is set by --video, but only as long as CACHEDIR is un-set. (Same applies to --config and RESDIR.)
I'm not sure whether this should also be the case if VDR is compiled to be FHS compliant. In that case users should know about the various folders, and setting a --video directory should not have precedence over CACHEDIR=/var/lib/vdr. The only thing I could think of is to check whether CACHEDIR==VIDEODIR, and only then let cacheDirectory follow --video, but I would prefer to not use such hacks.
Currently VDR has only two directories, 'video' and 'config'. The idea is that by default the video directory is /video, and the config directory is the same. If -v is given, this changes the video directory, and since config follows video (or at least is supposed to), the config files will be loaded from the new video directory. Only if there is an explicit -c option shall the config directory be different from the video directory.
I'd like to see a similar mechanism for the two new directories 'cache' and 'resource'. By default they follow 'config' and can only be different if the respective options are given. The default values for 'cache' and 'resource' shall be empty, in which case they follow 'config'. If VDR is compiled with non-empty values for 'cache' and/or 'resource', simply let them no longer follow 'config' (same behavior as if a command line option has been given).
Don't know whether the patch already behaves this way (haven't checked), but that's the way it should be.
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Klaus Schmidinger wrote:
On 09.05.2012 16:36, Manuel Reimer wrote:
what is the current status in this topic? Anyone working on this?
Attached is a revised version of the patch, as I intend to adopt it in version 1.7.30.
Looks like I missed the discussion when this patch was posted originally. Here are my 2¢'s:
+VIDEODIR = /srv/vdr/video
Using /srv is fishy and some distros like Fedora even disallow packages to put anything there. Recordings are automatically created and potentially also automatically deleted. Some of them you want to keep and some you delete after watching. So IMHO they are some kind of spool file where either the machine or a human decides about their fate. So nine years ago when I started packaging vdr for SUSE I decided to use /var/spool/video (could have been /var/spool/vdr too). The second best candidate would be /var/lib/vdr/something I think.
+CONFDIR = /var/lib/vdr
Even though vdr may update some of the files there itself I still think they belong to /etc to make sure they are included in backups by default.
What's missing is a directory for include files to be able to build plugins separate from vdr.
cu Ludwig
On 03.09.2012 15:42, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
On 09.05.2012 16:36, Manuel Reimer wrote:
what is the current status in this topic? Anyone working on this?
Attached is a revised version of the patch, as I intend to adopt it in version 1.7.30.
Looks like I missed the discussion when this patch was posted originally. Here are my 2¢'s:
+VIDEODIR = /srv/vdr/video
Using /srv is fishy and some distros like Fedora even disallow packages to put anything there. Recordings are automatically created and potentially also automatically deleted. Some of them you want to keep and some you delete after watching. So IMHO they are some kind of spool file where either the machine or a human decides about their fate. So nine years ago when I started packaging vdr for SUSE I decided to use /var/spool/video (could have been /var/spool/vdr too). The second best candidate would be /var/lib/vdr/something I think.
+CONFDIR = /var/lib/vdr
Even though vdr may update some of the files there itself I still think they belong to /etc to make sure they are included in backups by default.
Since I myself only use the "one single /video directory mode", I absolutely don't care what paths are used in FHS mode. Therefore I'll put in there whatever the community agrees upon (although I doub't that there will ever be an agreement ;-).
So anybody who feels like it, please post the necessary patch here, and let me know whether or not it should go into the VDR source.
What's missing is a directory for include files to be able to build plugins separate from vdr.
Makefile: INCDIR?
Klaus
2012/9/3 Ludwig Nussel ludwig.nussel@suse.de:
Klaus Schmidinger wrote:
On 09.05.2012 16:36, Manuel Reimer wrote:
what is the current status in this topic? Anyone working on this?
Attached is a revised version of the patch, as I intend to adopt it in version 1.7.30.
Looks like I missed the discussion when this patch was posted originally. Here are my 2¢'s:
+VIDEODIR = /srv/vdr/video
Using /srv is fishy and some distros like Fedora even disallow packages to put anything there. Recordings are automatically created and potentially also automatically deleted. Some of them you want to keep and some you delete after watching. So IMHO they are some kind of spool file where either the machine or a human decides about their fate. So nine years ago when I started packaging vdr for SUSE I decided to use /var/spool/video (could have been /var/spool/vdr too). The second best candidate would be /var/lib/vdr/something I think.
FHS 2.3 (http://www.pathname.com/fhs/pub/fhs-2.3.pdf) says:
/var/spool contains data which is awaiting some kind of later processing. Data in /var/spool represents work to be done in the future (by a program, user, or administrator); often data is deleted after it has been processed.
I don't think that this applies to recordings.
+CONFDIR = /var/lib/vdr
Even though vdr may update some of the files there itself I still think they belong to /etc to make sure they are included in backups by default.
Some people mount their /etc read-only. This would break VDR's functionality. Nevertheless we already talked about this and most people agree with /var/lib/vdr
What's missing is a directory for include files to be able to build plugins separate from vdr.
Christopher
Christopher Reimer wrote:
2012/9/3 Ludwig Nussel ludwig.nussel@suse.de:
Klaus Schmidinger wrote:
On 09.05.2012 16:36, Manuel Reimer wrote:
what is the current status in this topic? Anyone working on this?
Attached is a revised version of the patch, as I intend to adopt it in version 1.7.30.
Looks like I missed the discussion when this patch was posted originally. Here are my 2¢'s:
+VIDEODIR = /srv/vdr/video
Using /srv is fishy and some distros like Fedora even disallow packages to put anything there. Recordings are automatically created and potentially also automatically deleted. Some of them you want to keep and some you delete after watching. So IMHO they are some kind of spool file where either the machine or a human decides about their fate. So nine years ago when I started packaging vdr for SUSE I decided to use /var/spool/video (could have been /var/spool/vdr too). The second best candidate would be /var/lib/vdr/something I think.
FHS 2.3 (http://www.pathname.com/fhs/pub/fhs-2.3.pdf) says:
/var/spool contains data which is awaiting some kind of later processing. Data in /var/spool represents work to be done in the future (by a program, user, or administrator); often data is deleted after it has been processed.
I don't think that this applies to recordings.
Well, after you've recorded something you do something with it. Like watching the recording, deleting it or let vdr delete it when it needs more free space. If you think of time shifting this matches a spool directory even more. Of course if your use case mostly is to record stuff to keep it forever then it doesn't quite match. But then such recordings should probably be moved to some kind of archive. In any case using /srv is odd for sure. Better use /var/lib/vdr/... rather than /srv.
+CONFDIR = /var/lib/vdr
Even though vdr may update some of the files there itself I still think they belong to /etc to make sure they are included in backups by default.
Some people mount their /etc read-only. This would break VDR's functionality. Nevertheless we already talked about this and most people agree with /var/lib/vdr
Currently that might be true. Nevertheless it would be good to enhance vdr to make it friendlier in that regard though. E.g treating short lived data like a one shot timer or automatically detected stations differently than actual configuration like the ordering of stations.
cu Ludwig
On Tue, Sep 4, 2012 at 12:38 AM, Ludwig Nussel ludwig.nussel@suse.de wrote:
Currently that might be true. Nevertheless it would be good to enhance vdr to make it friendlier in that regard though. E.g treating short lived data like a one shot timer or automatically detected stations differently than actual configuration like the ordering of stations.
Why would you assume single timer recordings, or any recordings at all are short-lived? If anything users tend to record shows and watch them at some point in the non-immediate future -- the weekend for example, when they're more likely to have time sitting around watching tv. I know several people who record entire series and don't even start watching them until all the episodes are recorded so they don't have the irritating wait of a week+ between them. Then there are houses, like mine, where one person will watch a recording one day, then somebody else will watch the same thing some days later.
By now you should get the point that assuming recordings are short-lived is bad, automatically deleting them is bad, etc. Typical user behavior from my observation certainly isn't record something, watch it immediately, then delete it.
Ludwig Nussel wrote: [Readonly /etc]
Currently that might be true. Nevertheless it would be good to enhance vdr to make it friendlier in that regard though. E.g treating short lived data like a one shot timer or automatically detected stations differently than actual configuration like the ordering of stations.
So you talk about "timers.conf" and "channels.conf"? They are both dynamic in the same way. VDR heavily modifies "channels.conf". Names, PIDs, .... are modified and even new channels are added completely automatically! If I move channels, add channels, ... via OSD, then VDR also modifies this file to store my changes.
Yours
Manuel
On Monday 03 September 2012 - 15:42:04, Ludwig Nussel wrote:
So nine years ago when I started packaging vdr for SUSE ...
Sorry, but Suse is not known for doing things right :( ... and they don't care much about system quality.
Even though vdr may update some of the files there itself I still think they belong to /etc to make sure they are included in backups by default.
FHS says about /etc: "The /etc hierarchy contains configuration files. A "configuration file" is a local file used to control the operation of a program; it must be static and cannot be an executable binary."
Keep you eyes on "it must be static"!
You could learn from debian systems, where the stuff in /etc is really static. Even with vdr. 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.
Regarding backup: If you allow your backup application to follow links and save the original, the databases will be saved.
But even better: Teach your SUSE-users to save /var/lib I believe, from backup point of view, /var/lib has the same or even higher importance to get saved, than /etc
I decided to use /var/spool/video (could have been /var/spool/vdr too).
That's a good point!
Lots of VDR-users use VDR as a standalone system and for those systems /var/spool might be more appropriate than /srv
/srv is right, if the VDR-machine offers the recordings like a NAS or MediaServer, so in case the VDR is a backend machine, it might be better to symlink /var/spool/video to /srv/video or the like.
kind regards
Gero
2012/9/4 Gero geronimo013@gmx.de:
I decided to use /var/spool/video (could have been /var/spool/vdr too).
That's a good point!
Lots of VDR-users use VDR as a standalone system and for those systems /var/spool might be more appropriate than /srv
/srv is right, if the VDR-machine offers the recordings like a NAS or MediaServer, so in case the VDR is a backend machine, it might be better to symlink /var/spool/video to /srv/video or the like.
The FHS gives further examples for /var/spool
"Printer spool directory" "Outgoing mail queue"
I cannot see how a recording directory is comparable with a printer or outgoing mail queue.
Christopher
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
On 04.09.2012 22:29, Manuel Reimer wrote:
... 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.
Feel free to contribute some code that implements an interactive DiSEqC setup menu ;-) The DiSEqC setup with all its possibilities is rather complex, and setting it up via a config file is simple enough for me, that's why I never bothered even trying to write a full-fledged setup page for it. But I'll gladly adopt a patch that does this in a useful way ;-)
Klaus
Manuel Reimer wrote:
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.
I'd still consider a file that is only modified if the user intentionally does so via the remote control static. There's no difference between that and using an editor except for the user interface.
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.
Well, that's your opinion.
/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
/srv in theory is taboo for distros (and it is in fact for Fedora) so distros will be forced to patch vdr to use something else. It's fine to use for a self compiled vdr but it's not for a distro package.
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.
We are forced to do that already anyways. If vdr changes anything wrt fs layout I'd really like to see something acceptable for distros to end the ranting about the different locations of /video.
Where are the vdr package maintainers of other distros hiding anyways?
cu Ludwig
2012/9/6 Ludwig Nussel ludwig.nussel@suse.de:
Manuel Reimer wrote:
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.
I'd still consider a file that is only modified if the user intentionally does so via the remote control static. There's no difference between that and using an editor except for the user interface.
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.
Well, that's your opinion.
It's also my opinion. And the opinion of many others e.g. yaVDR Maintainers. OK timeshift recordings could be saved to /var/spool, but for most people the recording directory is more like an archive.
/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
/srv in theory is taboo for distros (and it is in fact for Fedora) so distros will be forced to patch vdr to use something else. It's fine to use for a self compiled vdr but it's not for a distro package.
I maintain build scripts for Archlinux (No, not ArchVDR) and there it's only "taboo" to install files there. A good example in Archlinux is httpd, nothing is installed to /srv but httpd is configured to search for website data there.
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.
We are forced to do that already anyways. If vdr changes anything wrt fs layout I'd really like to see something acceptable for distros to end the ranting about the different locations of /video.
Where are the vdr package maintainers of other distros hiding anyways?
There is a thread about FHS in the German forum VDR-Portal (http://www.vdr-portal.de/board60-linux/board14-betriebssystem/111165-vdr-ver...)
Ludwig Nussel wrote:
I'd still consider a file that is only modified if the user intentionally does so via the remote control static. There's no difference between that and using an editor except for the user interface.
The difference is, that /etc is mounted readonly on some distributions (like Debian)! This is OK if you only do changes in very rare cases. In this cases, you just remount /etc with writing enabled for that short time.
This doesn't work with VDR. Especially as there doesn't have to be user interaction for the files to be modified. VDR changes channels.conf pretty often even without the user knowing about that. If you use "epgsearch", then "timers.conf" is modified regularly depending on the channels EPG data, ...
This is why such stuff should go below /var/lib.
/srv in theory is taboo for distros (and it is in fact for Fedora) so distros will be forced to patch vdr to use something else.
No need to patch anything. Just prepare your own "Make.config" and place into the source directory before you start building VDR.
It's fine to use for a self compiled vdr but it's not for a distro package.
I searched the web and for me it seems like even OpenSuSE uses /srv/www to store the "service relevant" data for the Apache webserver. So why is this OK for Apache but bad for VDR?
VDR does not *install* files to the VIDEODIR, by default. It just uses it to store recordings.
Yours
Manuel
Klaus Schmidinger wrote:
Attached is a revised version of the patch, as I intend to adopt it in version 1.7.30.
Didn't try it, so far, but I had a look at it and maybe, I've found a small problem:
+# By default VDR requires only one single directory to operate: VIDEODIR = /video -CONFDIR = $(VIDEODIR) +# See Make.config.template if you want to build VDR according to the FHS ("File system Hierarchy Standard")
[...]
+ +install-conf: + @cp *.conf $(DESTDIR)$(CONFDIR)
For me this seems like "install-conf" does not longer work if FHS is *not* used, as "CONFDIR" is not defined without the FHS mode enabled?
Yours
Manuel
On 06.09.2012 21:09, Manuel Reimer wrote:
Klaus Schmidinger wrote:
Attached is a revised version of the patch, as I intend to adopt it in version 1.7.30.
Didn't try it, so far, but I had a look at it and maybe, I've found a small problem:
+# By default VDR requires only one single directory to operate: VIDEODIR = /video -CONFDIR = $(VIDEODIR) +# See Make.config.template if you want to build VDR according to the FHS ("File system Hierarchy Standard")
[...]
+install-conf:
- @cp *.conf $(DESTDIR)$(CONFDIR)
For me this seems like "install-conf" does not longer work if FHS is *not* used, as "CONFDIR" is not defined without the FHS mode enabled?
Mabe this would help:
--- Makefile 2012/09/01 13:22:33 2.28 +++ Makefile 2012/09/07 10:31:35 @@ -76,6 +76,10 @@ DEFINES += -DPLUGINDIR="$(PLUGINLIBDIR)" DEFINES += -DLOCDIR="$(LOCDIR)"
+CONFDIR ?= $(VIDEODIR) +CACHEDIR ?= $(VIDEODIR) +RESDIR ?= $(CONFDIR) + # The version numbers of VDR and the plugin API (taken from VDR's "config.h"):
VDRVERSION = $(shell sed -ne '/define VDRVERSION/s/^.*"(.*)".*$$/\1/p' config.h)
Please let me know if this should be added.
Klaus
Am 07.09.2012 12:33, schrieb Klaus Schmidinger:
On 06.09.2012 21:09, Manuel Reimer wrote:
Klaus Schmidinger wrote:
Attached is a revised version of the patch, as I intend to adopt it in version 1.7.30.
Didn't try it, so far, but I had a look at it and maybe, I've found a small problem:
+# By default VDR requires only one single directory to operate: VIDEODIR = /video -CONFDIR = $(VIDEODIR) +# See Make.config.template if you want to build VDR according to the FHS ("File system Hierarchy Standard")
[...]
+install-conf:
- @cp *.conf $(DESTDIR)$(CONFDIR)
For me this seems like "install-conf" does not longer work if FHS is *not* used, as "CONFDIR" is not defined without the FHS mode enabled?
Mabe this would help:
--- Makefile 2012/09/01 13:22:33 2.28 +++ Makefile 2012/09/07 10:31:35 @@ -76,6 +76,10 @@ DEFINES += -DPLUGINDIR="$(PLUGINLIBDIR)" DEFINES += -DLOCDIR="$(LOCDIR)"
+CONFDIR ?= $(VIDEODIR) +CACHEDIR ?= $(VIDEODIR) +RESDIR ?= $(CONFDIR)
- # The version numbers of VDR and the plugin API (taken from VDR's
"config.h"):
VDRVERSION = $(shell sed -ne '/define VDRVERSION/s/^.*"(.*)".*$$/\1/p' config.h)
Please let me know if this should be added.
Hmm, CONFDIR ist already defined in the Makefile.
On 07.09.2012 13:04, Christopher Reimer wrote:
Am 07.09.2012 12:33, schrieb Klaus Schmidinger:
On 06.09.2012 21:09, Manuel Reimer wrote:
Klaus Schmidinger wrote:
Attached is a revised version of the patch, as I intend to adopt it in version 1.7.30.
Didn't try it, so far, but I had a look at it and maybe, I've found a small problem:
+# By default VDR requires only one single directory to operate: VIDEODIR = /video -CONFDIR = $(VIDEODIR) +# See Make.config.template if you want to build VDR according to the FHS ("File system Hierarchy Standard")
[...]
+install-conf:
- @cp *.conf $(DESTDIR)$(CONFDIR)
For me this seems like "install-conf" does not longer work if FHS is *not* used, as "CONFDIR" is not defined without the FHS mode enabled?
Mabe this would help:
--- Makefile 2012/09/01 13:22:33 2.28 +++ Makefile 2012/09/07 10:31:35 @@ -76,6 +76,10 @@ DEFINES += -DPLUGINDIR="$(PLUGINLIBDIR)" DEFINES += -DLOCDIR="$(LOCDIR)"
+CONFDIR ?= $(VIDEODIR) +CACHEDIR ?= $(VIDEODIR) +RESDIR ?= $(CONFDIR)
- # The version numbers of VDR and the plugin API (taken from VDR's
"config.h"):
VDRVERSION = $(shell sed -ne '/define VDRVERSION/s/^.*"(.*)".*$$/\1/p' config.h)
Please let me know if this should be added.
Hmm, CONFDIR ist already defined in the Makefile.
Not after vdr-1.7.29-fhs.diff has been applied. The above addition is meant to be made after applying that patch.
Klaus
On 07.09.2012 13:26, Klaus Schmidinger wrote:
On 07.09.2012 13:04, Christopher Reimer wrote:
Am 07.09.2012 12:33, schrieb Klaus Schmidinger:
On 06.09.2012 21:09, Manuel Reimer wrote:
Klaus Schmidinger wrote:
Attached is a revised version of the patch, as I intend to adopt it in version 1.7.30.
Didn't try it, so far, but I had a look at it and maybe, I've found a small problem:
+# By default VDR requires only one single directory to operate: VIDEODIR = /video -CONFDIR = $(VIDEODIR) +# See Make.config.template if you want to build VDR according to the FHS ("File system Hierarchy Standard")
[...]
+install-conf:
- @cp *.conf $(DESTDIR)$(CONFDIR)
For me this seems like "install-conf" does not longer work if FHS is *not* used, as "CONFDIR" is not defined without the FHS mode enabled?
Mabe this would help:
--- Makefile 2012/09/01 13:22:33 2.28 +++ Makefile 2012/09/07 10:31:35 @@ -76,6 +76,10 @@ DEFINES += -DPLUGINDIR="$(PLUGINLIBDIR)" DEFINES += -DLOCDIR="$(LOCDIR)"
+CONFDIR ?= $(VIDEODIR) +CACHEDIR ?= $(VIDEODIR) +RESDIR ?= $(CONFDIR)
- # The version numbers of VDR and the plugin API (taken from VDR's
"config.h"):
VDRVERSION = $(shell sed -ne '/define VDRVERSION/s/^.*"(.*)".*$$/\1/p' config.h)
Please let me know if this should be added.
Hmm, CONFDIR ist already defined in the Makefile.
Not after vdr-1.7.29-fhs.diff has been applied. The above addition is meant to be made after applying that patch.
Well, my above suggestion doesn't work as expected because of the recursive variable expansion done by 'make'.
The following appears to work, though:
------------------------------------------------------------------------------------------- --- Makefile 2012/09/01 13:22:33 2.28 +++ Makefile 2012/09/07 14:11:37 @@ -76,6 +76,12 @@ DEFINES += -DPLUGINDIR="$(PLUGINLIBDIR)" DEFINES += -DLOCDIR="$(LOCDIR)"
+# Default values for directories: + +CONFDIRDEF = $(firstword $(CONFDIR) $(VIDEODIR)) +CACHEDIRDEF = $(firstword $(CACHEDIR) $(VIDEODIR)) +RESDIRDEF = $(firstword $(RESDIR) $(CONFDIRDEF)) + # The version numbers of VDR and the plugin API (taken from VDR's "config.h"):
VDRVERSION = $(shell sed -ne '/define VDRVERSION/s/^.*"(.*)".*$$/\1/p' config.h) @@ -112,10 +118,10 @@ vdr.pc: Makefile Make.global @echo "bindir=$(BINDIR)" > $@ @echo "includedir=$(INCDIR)" >> $@ - @echo "configdir=$(CONFDIR)" >> $@ + @echo "configdir=$(CONFDIRDEF)" >> $@ @echo "videodir=$(VIDEODIR)" >> $@ - @echo "cachedir=$(CACHEDIR)" >> $@ - @echo "resdir=$(RESDIR)" >> $@ + @echo "cachedir=$(CACHEDIRDEF)" >> $@ + @echo "resdir=$(RESDIRDEF)" >> $@ @echo "plugindir=$(PLUGINLIBDIR)" >> $@ @echo "localedir=$(LOCDIR)" >> $@ @echo "apiversion=$(APIVERSION)" >> $@ @@ -200,12 +206,12 @@
install-dirs: @mkdir -p $(DESTDIR)$(VIDEODIR) - @mkdir -p $(DESTDIR)$(CONFDIR) - @mkdir -p $(DESTDIR)$(CACHEDIR) - @mkdir -p $(DESTDIR)$(RESDIR) + @mkdir -p $(DESTDIR)$(CONFDIRDEF) + @mkdir -p $(DESTDIR)$(CACHEDIRDEF) + @mkdir -p $(DESTDIR)$(RESDIRDEF)
install-conf: - @cp *.conf $(DESTDIR)$(CONFDIR) + @cp *.conf $(DESTDIR)$(CONFDIRDEF)
# Documentation: -------------------------------------------------------------------------------------------
Klaus
Udo Richter wrote:
Ok, second attempt:
- Makefile does not set CACHEDIR and RESDIR
- Make.config *can* set CACHEDIR and RESDIR, or not.
- If --cachedir or --resdir is set by command line, use them.
- If not, default to CACHEDIR and RESDIR.
- If CACHEDIR or RESDIR is not set (empty string), fall back to whatever
--video and --config is set to.
Patched patch attached. ;) Needs documentation updated though.
Do so. I guess it is nearly impossible to document this in a way, a user actually understands.
Yours
Manuel
FHS patch
This change would be welcome (I'm the VDR package maintainer of Mageia distribution), though it hasn't really been a big issue for me.
A couple of comments regarding the INSTALL part:
06.04.2012 16:01, Christopher Reimer kirjoitti:
+CACHEDIR = /var/cache/vdr
+CONFDIR = /var/lib/vdr
Just for the record, this is a bit against FHS rules ("Users must never need to modify files in /var/lib to configure a package's operation."), but there really is not better option either... (maybe fhs-discuss@ could be asked for a clarification).
+LOCDIR = $(PREFIX)/share/locale +PLUGINLIBDIR = $(PREFIX)/lib/vdr +RESDIR = $(PREFIX)/share/vdr
+VIDEODIR = /srv/vdr/video0
Ditto here, "/srv contains site-specific data which is served by this system.", which video data really isn't. (btw, why 'video0' and not 'video' like is VDR default?)
On Mandriva/Mageia packages I use '/var/lib/vdr/config' and '/var/lib/vdr/video', but as I said, they aren't really any better than your suggestions :)
Maybe just add a note that the INSTALL example doesn't really conform to current FHS?
On Sat, 07 Apr 2012 19:24:17 +0300 Anssi Hannula anssi.hannula@iki.fi wrote:
FHS patch
This change would be welcome (I'm the VDR package maintainer of Mageia distribution), though it hasn't really been a big issue for me.
A couple of comments regarding the INSTALL part:
06.04.2012 16:01, Christopher Reimer kirjoitti:
+CACHEDIR = /var/cache/vdr
+CONFDIR = /var/lib/vdr
Just for the record, this is a bit against FHS rules ("Users must never need to modify files in /var/lib to configure a package's operation."), but there really is not better option either... (maybe fhs-discuss@ could be asked for a clarification).
vdr has 2 types of conf files - 1) internal databases - like channels.conf, setup.conf 2) real conf files like scr.conf, diseqc.conf etc
1 should be in /var/lib/vdr 2 should be in /etc/vdr/
This is kind of hard to handle properly as vdr doesn't make this distinction. conf files in /var/lib is a no-go, application changed files in /etc is a no-go either.
+LOCDIR = $(PREFIX)/share/locale +PLUGINLIBDIR = $(PREFIX)/lib/vdr +RESDIR = $(PREFIX)/share/vdr
+VIDEODIR = /srv/vdr/video0
Ditto here, "/srv contains site-specific data which is served by this system.", which video data really isn't. (btw, why 'video0' and not 'video' like is VDR default?)
If video is served by vdr or not is a bit of opinion. IMHO recordings is THE data served by vdr, it should not be hidden somewhere in /var/lib , in yavdr we also make it available in the local network by smb and nfs - those we use this directory. video0 , because it allows for easy extension of storage space, without reconfiguring vdr, video1, video2 and videoX will be used autmatically by vdr at next start.
On Mandriva/Mageia packages I use '/var/lib/vdr/config' and '/var/lib/vdr/video', but as I said, they aren't really any better than your suggestions :)
Maybe just add a note that the INSTALL example doesn't really conform to current FHS?
On 07.04.2012 20:03, Steffen Barszus wrote:
...
+VIDEODIR = /srv/vdr/video0
... video0 , because it allows for easy extension of storage space, without reconfiguring vdr, video1, video2 and videoX will be used autmatically by vdr at next start.
Note, though, that after version 2.0 this "multiple disk handling" will be deprecated and later dropped. So I suggest in a template it should be /srv/vdr/video, without the '0' at the end.
Klaus
Klaus Schmidinger wrote:
Note, though, that after version 2.0 this "multiple disk handling" will be deprecated and later dropped. So I suggest in a template it should be /srv/vdr/video, without the '0' at the end.
In my opinion, this way a great feature of VDR would be lost. There is *no* alternative to easily add more space to VDR.
Yours
Manuel
On 08.04.2012 09:51, Manuel Reimer wrote:
Klaus Schmidinger wrote:
Note, though, that after version 2.0 this "multiple disk handling" will be deprecated and later dropped. So I suggest in a template it should be /srv/vdr/video, without the '0' at the end.
In my opinion, this way a great feature of VDR would be lost.
This method may have been useful in the old days where large harddisks were unavailable or hard to come by. Now we're living in the age of terabyte disks, and setting up a VDR with 1TB of video storage (even using a second disk to have a RAID-1 for data safety) os no big deal any more.
There is *no* alternative to easily add more space to VDR.
Isn't LVM the keyword here?
At any rate, I want to get rid of that symlink stuff and allow VDR to "see" only one big video directory. Of course there may still be other volumes mounted on subdirectories of that video directory.
Klaus
Klaus Schmidinger wrote:
This method may have been useful in the old days where large harddisks were unavailable or hard to come by. Now we're living in the age of terabyte disks, and setting up a VDR with 1TB of video storage (even using a second disk to have a RAID-1 for data safety) os no big deal any more.
Especially with HDTV the amount of disc space, used for recordings, also got bigger.
Isn't LVM the keyword here?
No. It is virtually impossible to just merge in a second disc if the first already has data on it and hasn't been set up as LVM physical volume on first install.
You would have to move all data to another disc to set up the first VDR disc from scratch with LVM. After setting up, all data has to be copied back. I think it requires several hours to set that up. With the VDR multiple disc feature, I just install the new disc and mount it --> Setup done.
Another big disadvantage of LVM is, that it is nearly impossible to restore data of one of the LVM discs, if only one disc is available. Means: If one disc dies, all recordings are gone.
At any rate, I want to get rid of that symlink stuff and allow VDR to "see" only one big video directory. Of course there may still be other volumes mounted on subdirectories of that video directory.
But then I would have to save recordings to those subdirectories on my own and VDR wouldn't even see that additional space. Means: The displayed disc usage would be unusable.
If it causes you trouble to keep that feature, then, of course, you should remove it, but I don't think that it really is obsolete nowadays. It still is the easiest way to add a second disc to a existing VDR installation without needing to move/copy/setup things for several hours.
Yours
Manuel
On Sun, 08 Apr 2012 11:54:21 +0200 "Manuel Reimer" Manuel.Reimer@gmx.de wrote:
Klaus Schmidinger wrote:
This method may have been useful in the old days where large harddisks were unavailable or hard to come by. Now we're living in the age of terabyte disks, and setting up a VDR with 1TB of video storage (even using a second disk to have a RAID-1 for data safety) os no big deal any more.
Especially with HDTV the amount of disc space, used for recordings, also got bigger.
Isn't LVM the keyword here?
No. It is virtually impossible to just merge in a second disc if the first already has data on it and hasn't been set up as LVM physical volume on first install.
You would have to move all data to another disc to set up the first VDR disc from scratch with LVM. After setting up, all data has to be copied back. I think it requires several hours to set that up. With the VDR multiple disc feature, I just install the new disc and mount it --> Setup done.
Another big disadvantage of LVM is, that it is nearly impossible to restore data of one of the LVM discs, if only one disc is available. Means: If one disc dies, all recordings are gone.
Try mhddfs - the only thing it misses from vdr behaviour (if partition size is chosen well) is to put the small files on another harddisk, then the bigger files (i.e. put index and info on 00 and all the rest somewhere else).
Knowing the history of bugs on that part (also, but not only in vdr core) its a wise choice to drop support for it (i say that even if i'm a user of that feature and like it a lot !)
On 08.04.2012 12:45, Steffen Barszus wrote:
On Sun, 08 Apr 2012 11:54:21 +0200 "Manuel Reimer"Manuel.Reimer@gmx.de wrote:
Klaus Schmidinger wrote:
This method may have been useful in the old days where large harddisks were unavailable or hard to come by. Now we're living in the age of terabyte disks, and setting up a VDR with 1TB of video storage (even using a second disk to have a RAID-1 for data safety) os no big deal any more.
Especially with HDTV the amount of disc space, used for recordings, also got bigger.
Isn't LVM the keyword here?
No. It is virtually impossible to just merge in a second disc if the first already has data on it and hasn't been set up as LVM physical volume on first install.
You would have to move all data to another disc to set up the first VDR disc from scratch with LVM. After setting up, all data has to be copied back. I think it requires several hours to set that up. With the VDR multiple disc feature, I just install the new disc and mount it --> Setup done.
Another big disadvantage of LVM is, that it is nearly impossible to restore data of one of the LVM discs, if only one disc is available. Means: If one disc dies, all recordings are gone.
Try mhddfs - the only thing it misses from vdr behaviour (if partition size is chosen well) is to put the small files on another harddisk, then the bigger files (i.e. put index and info on 00 and all the rest somewhere else).
Now that sounds like a very good alternative! I'd say this puts the final nail into this VDR feature's coffin ;-)
Knowing the history of bugs on that part (also, but not only in vdr core) its a wise choice to drop support for it (i say that even if i'm a user of that feature and like it a lot !)
Well put ;-)
BTW: let's not hijack this thread any longer (sorry for doing this initially). This is about the FHS patch, so let's hear ACKs or NACKs for that.
Klaus
Klaus Schmidinger wrote:
Try mhddfs
Now that sounds like a very good alternative! I'd say this puts the final nail into this VDR feature's coffin ;-)
ACK. Revoking my vote for the old feature. I hope that mhddfs is well maintained. Seems to be a pretty good alternative. Still a bit work to set up but much easier and has less disadvantages as LVM.
BTW: let's not hijack this thread any longer (sorry for doing this initially). This is about the FHS patch, so let's hear ACKs or NACKs for that.
ACK from me, but without the last additions by Christopher (more complex handling of directory paths based on whether the new parameters to VDR are given).
My primary focus is on the "Resource Directory" but the "Cache Directory" is a nice addition. So far, many plugin developers place resource data in the "Config Directory", just as this directory can easily be retrieved via plugin API.
I agree that, in theory, we would need another directory for "non VDR writable config files" like the svdrphosts.conf file, but I think we should at first take what we have. Future additions are always possible.
Yours
Manuel
2012/4/8 Manuel Reimer Manuel.Reimer@gmx.de
ACK from me, but without the last additions by Christopher (more complex handling of directory paths based on whether the new parameters to VDR are given).
Yes, I also think it's better to not use these additions. It's complex and I don't see any reason for them. Usually everything which is set in Make.config is right.
On Sunday 08 April 2012 - 11:36:18, Klaus Schmidinger wrote:
On 08.04.2012 09:51, Manuel Reimer wrote:
In my opinion, this way a great feature of VDR would be lost.
This method may have been useful in the old days where large harddisks were unavailable or hard to come by. Now we're living in the age of terabyte disks, and setting up a VDR with 1TB of video storage (even using a second disk to have a RAID-1 for data safety) os no big deal any more.
There is *no* alternative to easily add more space to VDR.
Isn't LVM the keyword here?
I agree to Manuel.
The possibility to extend an exhausted video-dir is unique to vdr and all quirks could be handled by simple scripting - opposed to quirks of lvm or the like.
The fact that nfs can not handle mounted subfs should be no reason to kill the vdrs videodir handling.
and beside that: I really love the feature to have splitted files. Even in days of terabyte drives - I use max filesize of 200 Mb, which has several advantages for me.
kind regards
Gero
Am 08.04.2012 11:36, schrieb Klaus Schmidinger:
At any rate, I want to get rid of that symlink stuff and allow VDR to "see" only one big video directory.
Sorry for being OT, just wanted to extend my thought of the last post-2.0-offtopic discussion: Modularize.
Defining an interface for 'video storage' thingys, together with the ability to have several storages loaded at the same time, would allow to have plain old /video storage and (maybe as plugin) remote network storages. It would also allow to have more than one local storage. (Maybe a storage backend that read/writes AVI or MKV?) And if the old, ugly symlink system gets dropped, it could even be continued by a compatibility plugin.
There are tons of more possibilities here, but we should delay that to post-2.0.
Cheers,
Udo
Steffen Barszus wrote:
vdr has 2 types of conf files -
- internal databases - like channels.conf, setup.conf
- real conf files like scr.conf, diseqc.conf etc
1 should be in /var/lib/vdr 2 should be in /etc/vdr/
I don't think so. VDR has two types of conf files, but they are:
- Files that are editable via OSD - Files that *should be* editable via OSD
IMHO VDR is the only receiver which requires me to log in via SSH to configure my DiSEqC settings.
Yours
Manuel
On Sunday 08 April 2012 - 09:54:52, Manuel Reimer wrote:
Steffen Barszus wrote:
vdr has 2 types of conf files -
- internal databases - like channels.conf, setup.conf
- real conf files like scr.conf, diseqc.conf etc
I don't think so. VDR has two types of conf files, but they are:
- Files that are editable via OSD
- Files that *should be* editable via OSD
Well, then the vdr has a third category of conf files:
- Files, that are written without user interaction
and such files are *definitely* *not* config-files, even if they have conf- extension. Some folks called such conf-files databases. Handle the writing of conf-files by user interaction (OSD or replacements) could be wrapped by a write-enablement-script or function, so config-files could stil reside on RO-media.
From my point of understanding, the FHS discussion is not focused on the config-files, that could not be managed by OSD, but is focused on the point, when config-files are written.
kind regards
Gero
-
Anssi Hannula -
Christopher Reimer -
Christopher Reimer -
Gero -
Klaus Schmidinger -
Ludwig Nussel -
Manuel Reimer -
Manuel Reimer
-
Mikko Tuumanen -
Pertti Kosunen -
Stefan Taferner -
Steffen Barszus -
Udo Richter -
VDR User