One reason the proposal came up for /srv is that the fhs is commonly asked by sysadmins for guidance as to where they should put data for services. On linux at least, /var/www and /home/www is common, though neither seem to fit into the definitions for those areas.
Is it so hard to broaden the definition of /var then?
The structure under /srv has been left undefined, with some suggestions as a non-normative rationale.
Being that the structure under /srv is left undefined we still end up with the same mess. /srv/database/postgresql or /srv/postgresql or /src/disk1/postgresql....
This does not solve a problem: /srv will still be a mess from distro to distro. Or, even worse, some distros may ignore /srv sticking to the previous LSB/FHS (undefined) waiting for clarification or changes in future versions of the FHS. So we'll end up with both /var /home /srv depending on the flavor of linux.
No, the rationale states that data of interest to a specific user should go in that user's home directory. Here is the full text of the rationale:
"This main purpose of specifying this is so that users may find the
location of the data files for particular service, and so that
services which require a single tree for readonly data, writable data
and scripts (such as cgi scripts) can be reasonably placed. Data that
is only of interest to a specific user should go in that users home
directory.
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 these locations."
This assumes data is arranged and stored in seprate places based off of services. rsync, cvs, ftp, and www can easily share the same target data.
Yup, we don't have FHS police :-) Admins do make local changes. In this case its more about setting up defaults for applications/packages to place or access their data.
Then please keep it out of / . If this is just to be a dumping ground for apps to leave their default junk we don't need to clutter up / with another dir do we? /var seems to have always been the ugly stepchild of unwanted crap... I'm fine with adding more to it... ;)
The /media entry doesn't bother me... but I'd rather see them redefine /mnt to be what most use it for anyway: exactly what they propose /media does. I can already visualize my inbox filling up for the mdk10 upgrade, "/mnt/cdrom is GONE!!! please FIX!!!!"
At the moment on linux we have /mnt/cdrom, /cdrom and /media/cdrom used. The main objection to /mnt/cdrom has been the older unix tradition of using /mnt as a temporary mount kind of scratch area. Though I do wonder how much this really matters these days.
Chris
-- Bryan Whitehead SysAdmin - JPL - Interferometry and Large Optical Systems Phone: 818 354 2903 [EMAIL PROTECTED]
