[Webapps-common-discuss] webapps-common/doc
PHP-Policy-Manual-DRAFT.sgml, NONE,
1.1 Webapps-Policy-Manual-DRAFT.sgml, 1.15, 1.16
seanius at haydn.debian.org
seanius at haydn.debian.org
Mon Jul 25 21:52:40 UTC 2005
Update of /cvsroot/webapps-common/webapps-common/doc
In directory haydn:/org/alioth.debian.org/chroot/home/users/seanius/tmp/cvs-serv9598
Modified Files:
Webapps-Policy-Manual-DRAFT.sgml
Added Files:
PHP-Policy-Manual-DRAFT.sgml
Log Message:
first attempt at starting the php policy seperate from webapps
--- NEW FILE: PHP-Policy-Manual-DRAFT.sgml ---
<!doctype debiandoc public "-//DebianDoc//DTD DebianDoc//EN">
<book>
<title>Webapps Policy Manual
<author>Alexis Sukrieh
<author>Pascal Hakim
<author>Neil McGovern
<author>Sean Finney
<version>
$Revision: 1.1 $
<abstract>
This manual describes the packaging standards of PHP within the
Debian GNU/Linux distribution, and the policy requirements
for packaged PHP applications, libraries, and add-on extensions.
<copyright>
Copyright © 2005 The Debian Webapps Team
<email>debian-webapps at lists.debian.org</email>.
<p>
This manual is free software; you may redistribute
it and/or modify it under the terms of the GNU
General Public License as published by the Free
Software Foundation; either version 2, or (at
your option) any later version.
<p>
This is distributed in the hope that it will
be useful, but without any warranty; without
even the implied warranty of merchantability or
fitness for a particular purpose. See the GNU
General Public License for more details.
<p>
A copy of the GNU General Public License is
available as /usr/share/common-licenses/GPL in the
Debian GNU/Linux distribution or on the World Wide
Web at the GNU General Public Licence. You can
also obtain it by writing to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA.
<toc sect1>
<chapt id="about">About this manual
<sect id="about-scope">Scope
<p>
This document is intended to apply to four specific groups
of packages in Debian GNU/Linux.
<list>
<item>PHP interpreters (such as php3, php4, and php5).
<item>Scripts and applications written in PHP.
<item>Software API's/libraries written in PHP.
<item>PHP extension modules (such as php4-mysql).
</list>
<sect id="about-authors">Authors and Maintainers
<p>
This policy manual has been written by
the members of the Debian Webapps Team:
<p>
<list>
<item>Alexis Sukrieh
<item>Pascal Hakim
<item>Neil McGovern
<item>Sean Finney
</list>
<p>
While the authors of this document
have tried hard to avoid typos and
other errors, these do still occur. If
you discover an error in this manual
or if you want to give any comments,
suggestions, or criticisms please send
an email to the Debian Webapps List,
<email>debian-webapps at lists.debian.org</email>,
or submit a bug report against the
<package>webapps-common</package> package.
<sect id="about-related">Related Documents
<p>
PHP is often one of many components that
constitute a "PHP application" found in
a typical debian package. There are many
inter-related issues in such packages that
fall outside the scope of this document.
There do exist other documents which
provide requirements and/or best practices
for such situations:
<list>
<item><url id="http://webapps-common.alioth.debian.org/doc/" name="Web Application Policy"> for covering issues specific to applications which
take part in a web-based interface.
<item><url id="http://people.debian.org/~seanius/policy/dbapp-policy.html" name="Database Application Policy"> for covering issues relating to interaction with database servers and management of application databases.
</list>
<sect id="terms">Terms and Conventions
<p>
<taglist>
<tag><item>do we need any?
</taglist>
<chapt id="php-int">PHP Interpreters
<sect id="php-interpreter-naming">Packages and naming scheme
<sect id="php-interpreter-fs">File and directory layout
<sect1 id="php-interpreter-fs-bins">PHP executable binaries
<sect1 id="php-interpreter-fs-include">Default include path
<sect1 id="php-interpreter-fs-conf">Configuration files
<chapt id="php-apps">PHP applications
<sect id="php-apps-naming">Packages and naming scheme
<sect id="php-apps-fs">File and directory layout
<chapt id="php-libs">PHP libraries
<sect id="php-libs-naming">Packages and naming scheme
<sect id="php-libs-fs">File and directory layout
<p>
PHP libraries should be located in
<tt>/usr/share/php/<var>PACKAGE</var></tt>.
<sect id="php-libs-pear">Requirements for PHP PEAR libraries
<chapt id="php-modules">PHP modules
<sect id="php-modules-naming">Packages and naming scheme
<sect id="php-modules-fs">File and directory layout
<p>
Precompiled binary modules
for PHP must be located in
<tt>/usr/lib/php<var>PHPVERSION</var>/<var>PHP_API_VERSION</var></tt>.
PHPVERSION is the numeric major
version number (such as 3, 4, or 5),
and PHP_API_VERSION is the version
against which the module was compiled.
The latter is defined at build-time in
<tt>/usr/include/php<var>PHPVERSION</var></tt>/main/php.h.
<p>
The following sed command can extract
the value of PHP_API_VERSION for php4:
<p>
<tt>sed -ne 's/\#define PHP_API_VERSION //p' < /usr/include/php4/main/php.h</tt>
<sect id="php-modules-registering">Registering and unregistering a PHP module
<p>
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 <tt>php.d</tt> directory
(<tt>/etc/php4/apache/php.d</tt>,
for example). Editing the contents
of <tt>php.ini</tt> 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 first prompting the admin, and
the default response for such a question
should be "false".
<p>
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 possible).
</book>
Index: Webapps-Policy-Manual-DRAFT.sgml
===================================================================
RCS file: /cvsroot/webapps-common/webapps-common/doc/Webapps-Policy-Manual-DRAFT.sgml,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -d -r1.15 -r1.16
--- Webapps-Policy-Manual-DRAFT.sgml 6 Jul 2005 03:39:18 -0000 1.15
+++ Webapps-Policy-Manual-DRAFT.sgml 25 Jul 2005 21:52:37 -0000 1.16
@@ -362,7 +362,10 @@
the web, they must not exist in a location
where they can be directly retrieved.
- <chapt id="libs">Includable files for web applications
+ <chapt id="issues-languages">Specific requirements for programming languages
+
+ <sect id="general">General
+ <sect1 id="libs">Includable files for web applications
<p>
The web application policy divides includable
files into two distinct categories:
@@ -379,52 +382,11 @@
security-related problems in poorly written web applications
are the direct result of not doing so.
- <sect id="libs-phplibs">PHP libraries
- <p>
- PHP libraries should be located in
- <tt>/usr/share/php/<var>PACKAGE</var></tt>.
- <p><em> FIXME: Perhaps PHP policy can eventually be split off into a seperate policy/manual, like perl?</em>
- <sect id="libs-phpmods">PHP modules
- <sect1 id="libs-phpmods-locations">PHP module locations
- <p>
- Precompiled binary modules for
- PHP must be located in
- <tt>/usr/lib/php<var>PHPVERSION</var>/<var>PHP_API_VERSION</var></tt>.
- PHPVERSION is the numeric major
- version number (such as 3, 4,
- or 5), and PHP_API_VERSION is
- the version against which the
- module was compiled. The latter
- is defined at build-time in
- <tt>/usr/include/php<var>PHPVERSION</var></tt>/main/php.h.
- <p>The following sed command can extract the value of
- PHP_API_VERSION for php4:
- <p>
- <tt>sed -ne 's/\#define PHP_API_VERSION //p' < /usr/include/php4/main/php.h</tt>
-
- <sect1 id="libs-phpmods-registering">Registering and unregistering a PHP module
- <p>
- 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 <tt>php.d</tt> directory
- (<tt>/etc/php4/apache/php.d</tt>,
- for example). Editing the contents
- of <tt>php.ini</tt> 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 first prompting the admin, and
- the default response for such a question
- should be "false".
- <p>
- 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 possible).
+ <sect id="php">PHP
+ <p>
+ point to the php policy.
+ <sect id="perl">Perl
+ point to the perl policy.
<chapt id="httpd"> Dealing with the webserver
<sect id="httpd-register">Registering a web application with a web server
More information about the Webapps-common-discuss
mailing list