Re: publicweb role

Tomas V.V.Cox wrote:

My point with "app" is "any file which isn't a lib, doc, test or extension, that needs to be located at a custom place by the person who installs the package". Either if it is a standalone application or (as you said) it's used by an application.

After some thought, I begin to see a way to tweak this idea to solve all the problems. The main problem I see that needs solving (which app role might be part of a solution) is that the URI to things like a javascript file must be hard-coded in a .js file that includes other .js files, and the same goes for .css files, or other static web-related things. replacements will only work once: if a config variable changes, they must be redone. With -c, they can be. This would require modifying the installer and registry, however. The registry is designed to keep track of a single installation location for a file. We would need to add a new registry file devoted to tracking each app-specific install, so that all of them will be uninstalled properly. for an environment like a multi-user installation (or a lazy single user one :), it would be good to have the -c option as a config variable, so that pear install -C Packagename would use this config variable (avoids typos which would be disastrous), or fail if it hasn't been set, and pear -c /special/path Packagename would use the command-line version you proposed. Note that every package which contains this app role should show a warning if neither -c nor -C is used, so users know about it. Maybe -C could be turned on by default? How does this sound: 1) scrap publicweb 2) add sub-roles for different kinds of application-specific data role="app" subrole="web" (what used to be publicweb) role="app" subrole="config" (configuration data like Pierre's ~/.pear/blah) 3) add configuration variables for the subroles which are blank by default, and can be set to automate application variable-specific installation. Also have a default subrole directory, which can be used for all. I think this separation will be necessary, as not all packages will want configuration files to be in a publicly accessible directory, for example, but will want web files to be accessible. 4) do a release soon of a PEAR that implements pre- and post-install scripts 5) do a release shortly after with the new app role, and make it depend on the PEAR version in point 4, so that users get the benefit of the pre- and post-install scripts that simply inform the user of what the new roles mean, and describe briefly where to find more information, and make a prominent note somewhere at pear.php.net which people can reference. The post-install script could also reference a local text file that contains all of the same instructions/explanation. Greg