This one time, at band camp, Steve Langasek said:
> On Sun, Jul 20, 2008 at 06:58:09PM +0100, Stephen Gran wrote:
> > > So you "vote" for an exemption from FSH in this case, as per
> > > 9.1.1?
> 
> > http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> 
> > "Therefore, no program should rely on a specific subdirectory
> > structure of /srv existing or data necessarily being stored in /srv.
> 
> I think it's perfectly in keeping with other parts of policy to ship
> our webservers with /srv/www as the default webroot, and leave it up
> to the administrator to symlink web applications into that root to
> enable them (or change the web root, or use aliases, etc).  In
> particular, Policy 11.5.4 says that web applications should avoid
> storing files in the web document root if possible.

So you think it's a good idea to ignore the the sentence above?  I agree
that it's a bad idea for applications to store things under the webroot
in general, but that's a seperate issue altogether to changing what the
default webroot points to.  If we could keep the seperate issues seperate
for the moment, I think it would be helpful.

a) applications installing random files under web root - bad
b) Changing httpds to ship a web root that either doesn't exist or would
   be wildly inappropriate on every system I admin - also bad.

Doing the change you recommend also has the downside of guaranteeing
that no web application that has to ship files under the web root can
work out of the box.  Admittedly these applications are probably silly,
but not currently buggy.
-- 
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        [EMAIL PROTECTED] |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

Attachment: signature.asc
Description: Digital signature

Reply via email to