Ryan Kavanagh <r...@debian.org> writes: > From FHS ยง5.8.1,
> This hierarchy holds state information pertaining to an application > or the system. State information is data that programs modify while > they run, and that pertains to one specific host. Users must never > need to modify files in /var/lib to configure a package's operation, > and the specific file hierarchy used to store the data must not be > exposed to regular users. > So, I think this suggestion of storing shiny-server (presumably > modifyable) configurations and served data in /var/lib/shiny-server > would violate policy. I would expect a workflow similar to that of the Apache packages. The default home page is a static file shipped with the package in /var, but one of the first things that any administrator does after installing the package is point it at a different docroot that suits their local file system layout. That avoids all of these problems, since there is no need to modify the static home page in order to make the package work. (Although the administrator can choose to do so if they want. I sometimes use /var to hold various configuration things on my systems. The actions of the local administrator are outside the scope of the FHS, which only constrains distributions. This is why we use /var rather than /usr, so that administrators can choose to just use /var if they feel like it without running into problems with, for example, a read-only /usr.) This issue comes up occasionally with different packages and we've never come up with a great solution beyond making it configurable at install (either via explicit documentation or via a debconf prompt). It's a bit of a gap in the FHS, in my opinion, but I'm not sure it's worth developing local policy to close the gap by, for instance, introducing a new top-level directory for default docroots for various services (I know of web, gopher, and tftp with this issue). We do try to hold the line on not installing files in /srv and not requiring any specific layout of /srv because the FHS is pretty explicit that the choice of directory layout in /srv is entirely up to the local administrator and distributions should not be messing with it. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
