As I've understood it, the new FHS recommends that one puts service data (that is, the kind of stuff normally in /var/www, /var/ftp, /var/svn etc.) in /srv instead of /var these days. See the URL for reference. I guess Gentoo should also move to /srv in that case, right?
There was a lot of talk about /srv a while ago on the gentoo-dev mailinglist. I suggest you check the archives. My memory is a little foggy, but i seem to recall that optional support for using /srv was discussed/implemented, but i'm not finding anything in the tree currently about it.
Know anything about this?
Yes. a) /srv is optional in the FHS. The FHS also doesn't define any structure at all under /srv. Part of the problem is that different organisations will benefit from layout out /srv in different ways. b) /srv is (AFAIK) only supported under SuSE atm. c) /var/www can already live under /srv - I run all my boxes that way. Same for /var/svn and /var/ftp. d) There is a GLEP for /srv support. I believe it's been approved, but tbh I think we should revisit it before implementing it. In lieu of a server TLP manager, I'm happy to own the bug if you want. Best regards, Stu
Stuart, I don't read your note a) as being entirely correct; here's a quote 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." The first sentence of that statement validates the second half of your note a), that there is no structure, but the second sentence states that /srv is actually not optional. In fact, at least to me, it says that it's mandatory. Since you're the author of GLEP 20, it's obvious you're in favor of supporting /srv, but I thought it would be useful to clarify the FHS's apparent position on the issue.
There seems little interest in making this happen. If someone else wants to fight the good fight, be my guest. Best regards, Stu
*** Bug 212631 has been marked as a duplicate of this bug. ***
Perhaps this would be best addressed on a Per-ebuild basis?
*** Bug 271982 has been marked as a duplicate of this bug. ***
