Re: annotated version of current CVS policy draft

[Gunnar Wolf <gwolf@gwolf.org>]

I have by far not been as active as I would have liked lately... I
have not even read the full document in the CVS, but at least, I have
some comments to do on your annotations :)

sean finney dijo [Mon, May 09, 2005 at 10:59:48PM -0400]:
> (...)
> i'm going to disagree with this.  i think that the applications should
> be completely agnostic of the document root, and provide access to
> themselves via apache aliases (or the equivalent).   some reasons:
> 
> - it will be much harder to preserve the admin's preferences on upgrades
>   (it would be hard to not recreate symlinks the admin deleted)
> - it makes assumptions about where the documentroot is
> - it could fail or overwrite non-package pre-existing data in the
>   documentroot

I completely agree with this. Besides, we are facing a /var/www =>
/srv/www transition, and we do not want that many packages making it
harder to move. And anyway, what most admins do under /var/www is as
varied as it can be - Packaged applications belong in
/usr/{lib,share}, and we must provide a way for them to be included
from the webserver's config files.

> (...)
> there are two very similar aproaches to this i'd like to discuss.
> 
> 1: place the webserver config in /etc/$package/apache.conf.  then, symlink to
>    that to /etc/$apache/conf.d/$package.conf.
> 2: place the webserver config in /etc/$apache/conf.d/$package.conf
>    directly.

A subtle comment: Yes, the vast majority of our users use any of the
Apache flavors as their webserver. We provide many other webservers -
And although their configurations are as varied as you can imagine, we
can try to make it more natural for them. 

I know doing this might be not that simple, and we would surely lose
richness of expression (and thus, configurability)... But what would
you think about this:

- Prepare a basic set of instructions usually found at a webapp
  Web server configuration (i.e., directory aliased to, script-alias,
  etc.) 
- Webapps should include a generic Debian Web server configuration
- Ask the maintainers of the different packages which provide httpd to
  include in their packaging a script to process Debian Web server
  configurations, producing valid configuration files or sections for
  their servers
- If a webserver does not support a particular feature (lets say, we
  are talking about a mod_perl package, which currently works only
  with Apache), the web server should send a meaningful error page
  when the webapp is requested, probably instructing the administrator
  to install a suitable webserver for that app
- If a new webserver is installed, the configurations for the existing
  webapps will still work without the hassle administrators face today
- The package installation will be more transparent, and will not have
  to ask the admin for obvious things (such as the typical 'which
  webserver is this package to be installed for').

How does this sound?

Greetings,

-- 
Gunnar Wolf - gwolf@gwolf.org - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF