Tollef Fog Heen wrote: > You can't know the structure of /srv, see the FHS rationale: > > The methodology used to name subdirectories of /srv is unspecified > as there is currently no consensus on how this should be done. One > method for structuring data under /srv is by protocol, eg. ftp, > rsync, www, and cvs. On large systems it can be useful to structure > /srv by administrative context, such as /srv/physics/www, > /srv/compsci/cvs, etc. This setup will differ from host to > host. Therefore, no program should rely on a specific subdirectory > structure of /srv existing or data necessarily being stored in > /srv. However /srv should always exist on FHS compliant systems and > should be used as the default location for such data. > > As long as the structure is unspecified, it is just about impossible > to me to have a sane default pointing to anywhere in /srv (except > directly at /srv itself) as that directory might very well not exist. > I would argue shipping a /srv/www is a bug if the site does not use > that layout.
Hmm, my reading of this has been that programs should default to using a directory in /srv (it says "should be used as the default location for such data"), but have to allow being configured to use any other directory in or out of /srv for thier data. Also that if program A is looking for program B's data, it cannot just assume that it's in some default location in /srv. So, for example, some of the tftp daemons in Debian have been configured to default to using /srv/tftpboot; they still have to be configurable to use other paths like /var/lib/tftpboot or /srv/intranet/tftpboot. And a program like the new di-netboot-assistant can't assume that /srv/tftpboot is the right place to dump files -- but it could ask with that as a default. I think that there's room for Debian to establish distro-wide policies for the *default* directories in /srv, as a suppliment to the FHS. -- see shy jo
signature.asc
Description: Digital signature
