Re: publicweb role

Tomas V.V.Cox wrote:

Well, multiple installations of the same package looks like a difficult thing to manage. AFAIK no other package manager supports it. The problem comes when a package contains for example lib files (role="php") and app files (role="app"). You'd end with file conflicts when try to install a package multiple times. Well, we could train the users to release two packages instead, one with lib files (for ex: foo-base) and another with app specific data (foo-webfiles). $ pear -c app_dir=xxx install foo-webfiles $ pear -c app_dir=yyy install foo-webfiles $ pear list foo-webfiles[1] foo-webfiles[2] No very clear. I don't see this as a working option - unnecessary clutter. Someone pointed out earlier that multiple installs can be handled either through a local pear installation, or through apache aliasing (other webservers can do the same thing, I suppose).

Basically, if the -c option exists, that is dynamically changing the configuration value - which opens up a can of worms that I don't think will work for packages. It basically makes it impossible to uninstall all the files associated with an application, which is a bad thing (TM).

Why not instead of "subrole" we create a new replacement type? For example: <file role="app" name="index.html"> <file role="app" name="config.php">

     <replace from="@web_uri@" to="web_uri" type="ask">
     Web uri is the absolut location of the root dir in your site
     </replace>

</file> I don't think interactive installation is a good idea in this case - if web_uri needs to be different for different packages, imagine the mess on pear upgrade-all. Unless you store the value somewhere, you need to ask again. Storing that value is the same as a config value, so it might as well be one.

I'm thinking that the -c option is too flexible to be maintainable, it needs to be a core config value specified at "pear install/upgrade PEAR" time or it will not work at all. instead of subroles, I think the solution is: <file role="app-web"> <file role="app-config"> and specify new configuration values for these roles. app-web_dir, app-web_uri, app-config_dir I prefer the name webdata for the first one, I still don't think it has anything to do with applications. The application data feature you are talking about is for data that may need to be installed at a different location for every single package. The stuff I'm talking about will never need to move - it has the same stability that role="php" does. In other words, the only time it moves is when the document root itself is moved, which is a huge deal for everything and not likely to happen any sooner than the PHP files will be moved. It's a different problem from application-specific custom data. Regards, Greg