On Sunday 23 March 2008, Axel Thimm wrote:
On Sun, Mar 23, 2008 at 10:20:10PM +0200, Ville Skyttä wrote:
> I suppose that's possible (didn't think of that, thanks), but will
> lead to more or less fragile config file modifications in
Why fragile? It either checks whether a previous vdr config told vdr
to put files there or looks whether /srv/vdr exists.
Previous config doesn't tell vdr anything, it uses compile time defaults,
ditto would most likely the new one. Deciding something based on
whether /srv/vdr exists is exactly the kind of fragility I mean. As is the
fact that we don't have a tool that could be reliably used to modify sourced
shell scripts (/etc/sysconfig/vdr) in the first place. Etc. There's a reason
why doing things like this is frowned upon.
> I'm leaning on the side of calling these modifications
> just leaving the data where it is in /srv
As said if the data is there leave it there.
Just in case it wasn't clear, I meant leaving not only the data there but the
package and its dir ownerships as is too.
If it is a new install
then have the user decide where he needs his data being placed in.
They can already configure it in /etc/sysconfig/vdr. Making it mandatory to
configure it manually is not something I'm going to inflict on users, stuff
needs to work out of the box to the extent possible. Users already need to
create channels.conf manually, that's bad enough.
> especially because there's no certainty how this issue will
> treated in the future (the draft contains things like "unclear" and
> "At this time").
These attributes including the "poor wording" are just spot's POV on
the FHS' stand on /srv.
Sounds like the draft needs some work.
In addition to the above, I think "don't touch anything in /srv but feel free
to make default configs tell apps to store data somewhere there" (which is
how I read the draft in a nutshell) doesn't sound good. For typical cases,
the only practical difference to creating and owning the data dir(s) there
would be that users would have to create them manually with the correct
ownerships and permissions.