On Sun, 2007-01-21 at 09:15 +1100, Ben Finney wrote: > Please follow the guidelines for Debian mailing lists: don't send me a > copy of messages unless I ask for one. I read the list. sorry, i'm still butting heads with my involuntarily new MUA, which doesn't have a shiny reply-to-list button (yes i know of ctrl-l, i just seem to forget a lot). > > On Sat, 2007-01-20 at 12:34 +1100, Ben Finney wrote: > Let's try reading that again: > > ... no program should rely on a specific subdirectory structure of > /srv existing or data necessarily being stored in /srv. ... > > which would apply if the package was going to *rely on the > subdirectory existing, or data necessarily being stored in /srv*, > which isn't the case. well, it would be a very bad thing if a default apache install spat out 404's because the document root didn't exist. personally, i would interpret that as relying on a specific subdirectory structure. > However /srv should always exist on FHS compliant systems > and should be used as the default location for such data. > > which applies if the package is going to configure a location to > *store data* that falls under the description of this section, "Data > for services provided by this system", which is the case. > > In which case, the FHS is explicit that "/srv ... should be used as > the default location for such data". > > So much for the FHS: it's clear that data such as that provided by a > web server should be stored somewhere under /srv. i think you and i are working with different interpretations of the terminology here. when i read "site-specific data", i interpret that as something /usr/local-ish, or even more so since we can not rely on subdirectory naming conventions (i.e. in /usr/local we can create package-specific subdirectories). my interpretation is that this is more of a guideline for the local administrator than it is for distributions. > > secondly, even if there were an outright conflict between debian > > policy and the FHS, debian policy wins wrt placement of files and > > directories in debian. > > That's true. Is there such a conflict? i don't believe so--that was more of a "even if you interpret the previous stuff differently from how i do". > The Debian Policy document doesn't specify what document root should > be configured by a web server; the closest I can find is: > > 11.5 Web servers and applications > [...] > 4. Web Document Root > > Web Applications should try to avoid storing files in the Web > Document Root. Instead they should use the /usr/share/doc/package > directory for documents and register the Web Application via the > doc-base package. If access to the web document root is > unavoidable then use > > /var/www > > as the Document Root. This might be just a symbolic link to the > location where the system administrator has put the real document > root. > which speaks only about what web *applications* should expect, and > doesn't speak about what the web *server* package should configure. i think that's some pretty selective interpretation. granted, nowhere is "Web Document Root" actually *defined*, and i'd say that's a policy bug. however, i think it's fair to understand it as the base directory for a web server, in which case it's clear that this is what the default setting for a web server's document root should be. again, you might fault policy for not being more clear by mixing this stuff in the same paragraph, but this would not be the only fault/omission in the web/http-related policy (see earlier post about new draft policy which has been in the works for some time) sean
Attachment:
signature.asc
Description: This is a digitally signed message part