On Mon, Jun 20, 2005 at 06:15:44PM +1000, Kai Hendry wrote: > On Mon, Jun 20, 2005 at 01:05:41AM -0700, Steve Langasek wrote: > > You can suggest it, but top-level directories are governed by the FHS, and > > you'll have to come up with a pretty strong reason why the existing > > available directories don't address the need. > So FHS suggests: > http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM > There is no consensus. It's a mess. I don't know what lack of consensus you're referring to. > > There's no way that Debian is going to create /web/example.com for you, and > Why not? Because of FHS? Because there's no infrastructure implementing this yet, and you are also not going to get everyone to agree that this is the one, true directory layout for services. If it's your intention to provide the infrastructure to create these directories, then ok -- but you ought to come up with a proof of concept first before asking that its use be mandated by policy. > > webapp packages certainly aren't going to populate that directory with their > > files on install, so what does it actually buy anyone to put this in policy? > Why not? Web apps should be be configured to do so. Just like they would > have to be for PACKAGE/www type structure. No, /usr/share/package/www is a single, fixed path per package containing the files shipped in the package. You're talking about something completely different which is *not* a replacement for /usr/share/package/www, because you *still* have to have some fixed location into which to unpack the files contained in the package. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature