On Sat, Oct 21, 2006 at 01:06:31PM +0200, Axel Thimm wrote:
No, /srv should exist, but otherwise be empty from the vendor's
POV
(e.g. no package should own/place anything beneath /srv). We should
neither impose /srv/<service>, nor /srv/<service>/<domain>, nor
/srv/<domain>/<service> methods. These are really very specific to the
solution needed and prefering any of these will make the other users
unhappy, and in this case all three mentioned solution have probably
the same or very comparable share of users.
I see it as analogous to /usr/local -- that's the local admin's domain, but
Fedora *does* populate it with some typical subdirectories.
I don't think it's at all unreasonable to ship with the default document
root at /srv/www, which would be empty by default. If you make anything else
the document root, many people are just going to edit stuff *there*.
Anyone who wants a different arrangement than the default can edit the
document root in httpd.conf, no problem, but there'd be a sensible and
standard default already. From the FHS:
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.
What I'm suggesting covers both parts of this, not just the first.
A copy-to-somewhere script could be rpovided, too. For example
fedora-install-mediawiki <path> or fedora-install-bugzilla <path> to
name two projects that are often used in several incarnations on one
system.
For some reason, this doesn't really feel right to me. Nothing else works
like this....
--
Matthew Miller mattdm(a)mattdm.org <
http://mattdm.org/>
Boston University Linux ------> <
http://linux.bu.edu/>