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@xxxxxxxxxx <http://mattdm.org/> Boston University Linux ------> <http://linux.bu.edu/> -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
