RFC: Installing vdr to /usr(/local)/sbin

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