Re: Re: semi-RFC: new file role needed: docroot

Hi there, I think it is a neat idea to have this level of customization. I worry that it will be impossible to debug. Isn't it easier to manually setup desired subdirectories of the publicweb_dir as a virtual host? With the current implementation of public_web, the only thing the script needs to ask is where to place the pear files. One thing that may benefit a local user would be a new command, pear install-web, which would only install files with role="public_web" with the assumption that there is a global install with the .php files. This will help those users who wish to use PEAR on a limited disk-space site. All you would need to do is set the environment variable to the local location. Another solution for a centralized pear with multiple users would be to allow the publicweb_dir config variable to be an array of paths. Then, each time a new package is installed or upgraded, it would install to all paths. Obviously, this would require a bit of finagling through scripting to add directories, but something like that shouldn't be generic anyways. This option might be useful for the role="data" as well. The installer would only need to add a check for the type of the config variable. Greg Stig S. Bakken wrote:

On Sat, 2003-07-26 at 00:33, Greg Beaver wrote:

Hi, I've been investigating the sources for PEAR, and an initial scan says it won't be easy to do, but that it will be possible to add a new configuration option, web document root. This will allow a new file role="web" to install into the document root, and therefore make available at a known URL all necessary files needed. This will also eliminate the problem of releasing a package with image files having role="php" This affects many packages in PEAR, including PEAR_Frontend_Web, HTML_TreeMenu, and phpDocumentor. Basically, any package that has a need to access files through html instead of PHP, whether javascript, css, or images needs this file role. If there is no objection, I would like to start working on implementing this so that at install-time, pear requests a document root directory for web install. I think that default behavior if the document root is not found should be to raise a warning, and then install into the data directory. After this is working, then a script can be written that will be executed upon pear upgrade PEAR which requests the new configuration value. This will also require the addition of a new file role, post-install or post-install-script, which specifies that the script should be run after installation. The zzoss installer has something like this, I believe, perhaps Sandro can comment.

I would suggesting having a template string in the PEAR configuration for this, for example: pear config-set htdocs_template /usr/local/apache/%s/htdocs %s is replaced by the application package name. This way, users may choose between installing individual application packages as their own virtual hosts, sub-directories or however Apache may be configured (being Apache biased for now). The uglyness of this is that you may not want to use the package name in the server name or path. Taking things a bit further, PEAR could instead generate a file for including from httpd.conf, per application package, that have a comment saying whether or not the installer is allowed to touch it again: # PEAR INSTALLER MAY MODIFY # replace "MAY" with "MAY NOT" (or something else) on the above line to # keep the file from being changed <VirtualHost *> ServerName pear-frontend-web.example.com DocumentRoot /usr/local/apache/PEAR_Frontend_Web/htdocs php_value include_path /usr/local/apache/PEAR_Frontend_Web/lib:/usr/local/lib/php </VirtualHost> In httpd.conf it's then just a matter of adding an Include per package or even have Include /path/to/pear/apacheconfs/*.conf - Stig