[Webapps-common-discuss] webapps-common/doc Webapps-Policy-Manual-DRAFT.txt,1.14,1.15

seanius@haydn.debian.org seanius@haydn.debian.org


Update of /cvsroot/webapps-common/webapps-common/doc
In directory haydn:/org/alioth.debian.org/chroot/home/users/seanius/tmp/cvs-serv696/doc

Modified Files:
	Webapps-Policy-Manual-DRAFT.txt 
Log Message:
more additions / changes

Index: Webapps-Policy-Manual-DRAFT.txt
===================================================================
RCS file: /cvsroot/webapps-common/webapps-common/doc/Webapps-Policy-Manual-DRAFT.txt,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -d -r1.14 -r1.15
--- Webapps-Policy-Manual-DRAFT.txt	10 May 2005 07:50:43 -0000	1.14
+++ Webapps-Policy-Manual-DRAFT.txt	11 May 2005 03:56:05 -0000	1.15
@@ -100,6 +100,7 @@
   - Alexis Sukrieh
   - Pascal Hakim
   - Neil McGovern
+  - Sean Finney
 
 FIXME: add here your name ;)
 
@@ -143,7 +144,7 @@
 dynamcially executed web pages              /usr/lib/cgi-bin/PACKAGE**
 application-specific libraries              /usr/share/PACKAGE/include***
 site configuration (settings/passwords)     /etc/PACKAGE
-locally modifiable/overridable content      /etc/PACKAGE****
+locally modifiable/overridable content      /etc/PACKAGE/templates****
 php libraries                               /usr/share/php/PACKAGE
 rrd, mrtg and other database files          see database application policy
 
@@ -156,6 +157,8 @@
 ***: other names, such as "lib" or "functions" are acceptable, as is anything
      else, as long as it is identifiable, outside the documentroot, and in
      a subdirectory of /usr/share/PACKAGE.
+****: once again, "templates" could be substituted with anything else
+      that makes sense, as long as it is a subdirectory of /etc/PACKAGE.
 
 
 2.2 Configuration Files and Customizable Content
@@ -231,12 +234,14 @@
 
 2.3 Database issues
 
-If the web application needs a database to run properly, the maintainer should use
-the dbconfig-common package to perform the database configuration.
-
-Please see the dbconfig-common manual[1] for details about how using this package.
+If the web application needs a database to run properly, it must abide by
+the database application policy[1].  the maintainer is highly encouraged
+to use a common tool such as dbconfig-common to perform the database
+configuration.  Please see the dbconfig-common manual[2] for details
+about how using this package.
 
-1: http://people.debian.org/~seanius/policy/examples/dbconfig-common/doc/dbconfig-common.html
+1: http://people.debian.org/~seanius/policy/dbapp-policy.html
+2: http://people.debian.org/~seanius/policy/dbconfig-common-using.html
 
 2.4 Architecture independent scripts (Perl, PHP and others)
 
@@ -275,61 +280,22 @@
 3.2.2 Registering and unregistering a php module
 
 FIXME sukria : should such a piece of code be provided by a webapps-common package?
+FIXME sean : same question as apache conf.d: symlinks or files?
 
-An entry should be placed in the relevent php.ini using postinst, if this is OK by the admin.
---- SAMPLE CODE ---
-for pkg in apache cli cgi; do
-    if [ -f /etc/php4/$pkg/php.ini ]; then
-        if ! grep -q "^[[:space:]]*extension[[:space:]]*=[[:space:]]*clam.so" /etc/php4/$pkg/php.ini; then
-            echo "You are installing ClamAV support for php4, but it's not"
-            echo "enabled in your /etc/php4/$pkg/php.ini."
-            echo
-            echo "To enable it you need to add this line:"
-            echo
-            echo "extension=clam.so"
-            echo
-            echo -n "Do you want me to add it now [Y/n] ?"
-            read a
-            if ! echo $a | grep -iq ^n; then
-                echo "extension=clam.so" >> /etc/php4/$pkg/php.ini
-            fi
-            fi
-    fi
-done
---- SAMPLE CODE ---
-
-FIXME sukria: same question as above
-
-Upon removal, the relevent entry in php.ini should be removed by prerm, if OK-ed by the admin
---- SAMPLE CODE ---
-for pkg in apache cli cgi; do
-    if [ -f /etc/php4/$pkg/php.ini ]; then
-        if grep -q "^[[:space:]]*extension[[:space:]]*=[[:space:]]*clam.so" /etc/php4/$pkg/php.ini; then
-            echo "You are removing ClamAV support for php4, but it is still"
-            echo "enabled in your /etc/php4/$pkg/php.ini."
-            echo
-            echo "You should remove this line:"
-            echo
-            echo "extension=clam.so"
-            echo
-            echo -n "Do you want me to do it now [Y/n] ?"
-            read a
-            if ! echo $a | grep -iq ^n; then
-                cat /etc/php4/$pkg/php.ini | \
-                    grep -v "^[[:space:]]*extension[[:space:]]*=[[:space:]]*clam.so" \
-                    > /etc/php4/$pkg/php.ini.clamremove
-                mv /etc/php4/$pkg/php.ini.clamremove /etc/php4/$pkg/php.ini
-            fi
-        fi
-    fi
-done
---- SAMPLE CODE ---
+Applications extending the abilities of php via add-on php modules should
+do so by placing symbolic links to any any relevant configuration files
+in the appropriate "php.d" directory (/etc/php4/apache/php.d, for
+example).  Editing the contents of php.ini files directly is strongly
+discouraged and should only be done if it is not possible to make changes
+via the previously described method.  In such cases, packages must not
+do so without prompting the admin, and the default response for such
+prompting should be "false".
 
-FIXME: 
-  Should this lot be handled by debconf?
+Upon package removal, packages can de-register themselves by simply
+removing the symbolic link in the php.d directory (this makes seperating
+de-activation from configuration purging much cleaner).
 
 FIXME sukria: 
-  Yes.
   Those piece of code sould be provided by our webapps-common package. The
   debconf question "do you want to register this php library?" should also be
   handled by our package, in the same philosophy than dbconfig-common: globalizing