important new features for application support in upcoming PEAR installer 1.7.0

Hi all, In the preparation for the release of Pyrus preview development release 1, I've added two significant new file roles to the PEAR Installer, which will appear in version 1.7.0, to be released very soon. The new file roles are "www" and "cfg." The "www" file role is intended to be used for public web files of a PEAR package. This is, for instance, where a web application would store its public frontend. This role is intended to obsolete the Role_Web "web" role available from pearified.com, and to fold this functionality into the core as an official component. The web role was not a part of PEAR originally because of doubts about its utility, but long usage in production environments such as the backend of pear.php.net have proved its design to be a good model. The most major difference between the "web" role and the "www" role is that the "www" role does not perform PHP file validation on its contents, which makes packaging image files and other binary files a possibility. Also important is that the "www" role respects the baseinstalldir attribute, allowing more flexible layout of files in the development environment. The "cfg" file role is intended to be used for configuration files that may be customized by the user, or even by the application itself. As such, the PEAR installer will never overwrite a configuration file. For example, let's say a configuration file in package Foo version 1.2.3 is named "config.xml." The user installs Foo version 1.2.3, resulting in the configuration file residing in: /usr/local/lib/php/cfg/Foo/config.xml The user later upgrades to Foo version 1.3.0, and some changes have been made to the configuration file. PEAR will detect these changes, and now these two files will exist: /usr/local/lib/php/cfg/Foo/config.xml /usr/local/lib/php/cfg/Foo/config.xml.new-1.3.0 If the user chooses to ignore the changes made to the configuration file, and later upgrades to version 1.3.1, the directory will now contain: /usr/local/lib/php/cfg/Foo/config.xml /usr/local/lib/php/cfg/Foo/config.xml.new-1.3.1 In other words, outdated configuration files are automatically erased. Applications can also choose to provide a post-install script that does merging of configuration files, this is something the PEAR installer does not control, and leaves up to application authors/users to handle. I would love feedback on the implementation of these two features, and will be providing a testing tarball of the PEAR installer shortly for the normal QA release process. Greg