[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

web application policy

Please let me know if this should be posted elsewhere. I am not a Debian
developper, but I see an issue that I think needs to be addressed, and
want to bring it up in the appropriate forum.

My experience installing multiple web appliations side by side is that
the Debian Policy Manual does not provide much guidance for web
applications, and each web application may place similar files in
different locations. The only official policy I was able to find is
[1]section 11.5 of the Debian Policy Manual.

1. http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-web-appl

Some of the areas which I think need clarification (based on
inconsistencies I have observed in current Debian packages) follow.
Perhaps these are already addressed in a document that I was unable to
locate in my brief search; in any case there are existing
inconsistencies in Debian packages.

- Where should dynamic data modified by cgi scripts be stored?
  usemod-wiki, squirrelmail, and spong use /var/lib, while blosxom uses
  /var/www. While I think that /var/www is obviously incorrect (see bug
  #230797), having a policy on where these should be located would be

- Where should icons be placed for reference from a cgi script? awstats
  currently uses /usr/share/awstats/icon. spong-www uses
  /usr/share/spong/www/gifs. blosxom uses /var/www/blosxom/images, and
  usemod-wiki uses /var/www/usemod-wiki. While I think that /var/www is
  obviously incorrect (see bug #229284 and #227928), having a policy on
  where these should be located would be helpful.

- How should web applications make themselves available in /var/www
  (this includes all content for php-style applications, and static
  content, including icons, for cgi-style applications). Currently there
  seems to be a split between creating a symbolic link from /var/www to
  somewhere in /usr/share, and creating an /etc/*/apache.conf file with
  the necessary rewrites. My persoanl feeling is that symbolic links are
  a more general solution than apache rewrites, as web servers other
  than Apache may be used, and rewrites are not well accomodated to
  virtual website hosting (which is a very natural, even effortless,
  extension of Apache 2.0).


A guy
Who wants
To middle-aisle it
Must never scratch
His little Violet

Reply to: