The web application policy divides includable files into two distinct categories: application-specific and site-wide. The former includes files not intended for use outside of the particular application in question, and the latter addresses files intended for more general use.
As previously mentioned, application-specific include files should exist in a unique subdirectory of /usr/share/PACKAGE. This subdirectory should exist outside of any web-accessible directory, as many security-related problems in poorly written web applications are the direct result of not doing so.
PHP libraries should be located in /usr/share/php/PACKAGE.
FIXME: Perhaps PHP policy can eventually be split off into a seperate policy/manual, like perl?
Precompiled binary modules for PHP must be located in /usr/lib/phpPHPVERSION/PHP_API_VERSION. 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 /usr/include/phpPHPVERSION/main/php.h.
The following sed command can extract the value of PHP_API_VERSION for php4:
sed -ne 's/\#define PHP_API_VERSION //p' < /usr/include/php4/main/php.h
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 first prompting the admin, and the default response for such a question should be "false".
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).
Webapps Policy Manual
$Revision: 1.15 $