As mentioned in a private mail to Klaus:
I tend to think /usr(/local)/sbin and manual page section 8 would be more appropriate for vdr than /usr(/local)/bin and section 1.
Even though "sbin" and section 8 is generally for "system administration commands", which vdr clearly is not, in my opinion vdr is even less a "user command" which "bin" and section 1 more or less implies. No need to clutter normal users' PATH with executables they aren't really supposed to run.
Additionally, the vast majority of daemon-like programs are installed to sbin directories by all distributions I'm aware of.
So, what do people think, would something like the attached patch be a good idea? It might break some setups, so it clearly needs to be done during a development cycle if ever. While sort of cosmetic, I think this would be a good thing, and in the series of making vdr feel "more mature" like someone mentioned in a recent "don't run as root" thread.
Obviously, after applying the patch, vdr.1 should be renamed to vdr.8.
Ville Skyttä wrote:
Even though "sbin" and section 8 is generally for "system administration commands", which vdr clearly is not, in my opinion vdr is even less a "user command" which "bin" and section 1 more or less implies. No need to clutter normal users' PATH with executables they aren't really supposed to run.
Well, that depends. The 'typical' use of VDR as recorder daemon, starting at boot time, would suggest this. However, I also have a secondary VDR on my notebook, relying on streamdev and xine-plugin, and in that case its really more an user process that is only started when needed.
On the other hand, I don't use the default make install anyway. ;)
Cheers,
Udo
Ville Skyttä schrieb:
As mentioned in a private mail to Klaus:
I tend to think /usr(/local)/sbin and manual page section 8 would be more appropriate for vdr than /usr(/local)/bin and section 1.
So, what do people think, would something like the attached patch be a good idea? It might break some setups, so it clearly needs to be done during a development cycle if ever. While sort of cosmetic, I think this would be a good thing, and in the series of making vdr feel "more mature" like someone mentioned in a recent "don't run as root" thread.
I support Udo's opinion too. We have a vdr running at work. It starts up as a daemon on boot. So this would match your argumentation. But we found out, that for cutting, it is easier to login to the vdr server and start a special vdr with softdevice(xv) output and (optional) streamdev-client input. The output is forwarded sufficiently fast via ssh-XForwarding in a Gigabit network. With this application in mind, I vote for not moving vdr to /usr/sbin.
Anyway, I also have my own installation method, and can handle the move on my side, too.
So long,
Patrick Cernko
-
Patrick Cernko -
Udo Richter -
Ville Skyttä