[mythtv-users] mythv 0.27 test packages (future RPM Fusion)

[Gary Buhrmaster]

On Fri, Sep 20, 2013 at 4:12 PM, Richard Shaw <hobbes1069 at gmail.com> wrote:
....
> True, but this is a fairly well used installation, so it's worth evaluating
> if the directory can be removed.

However, have you ever used the video functionality?
The code uses the /video/ subdir of .../data/  (in at
least some of the code, for some code paths).  And
the git commits for the app show creating the .../data/
and subdirs specifically so that the app works correctly
for all cases, not just what one sees on their system.

I agree that one could review the app and determine
if there are (now) unused subdirs based on current
patches.  But if that is so, one should apply the patches
"upstream" (i.e. in mythweb itself).

> Per the guidelines[1] /usr/share is preferred, though presumably that's
> intended for static data...

Exactly.  And this app is not all static data.

> It also mentions not using /var/www because 1)
> user may already have data there, and 2) it's not part of FHS anymore.

"base" /var/www is certainly not optimal (although
subdirs might be acceptable in some cases).  However,
neither is writing in /usr/share :-)

....
> Since the recommendation for mythweb is to run with SELinux off, I'm
> starting to like the idea of symbolic links to somewhere in /var or
> /var/cache for writable stuff.

I believe the FHS suggests /var/cache/www/ or /var/cache/<app>/
as a possible locations, but it also clearly states that anything
under /var/cache/<whatever> must have the app support
having the content disappear (usually because of running out
of disk space, and the system admin deleting the caches),
and I am have not reviewed the code to insure that mythweb
will support a system admin deleting the files while it is running
(one would have to test).  In theory it should, but we do have
practice (which may be different).

Note that apache must be configured to follow symlinks.
The default conf only follows symlinks under the .../data/
directory (not the base one).  There are numerous
potential solutions to that issue, of course.

But, now that you are on it, I will let you properly fix
and test it.

Thanks.

Gary