Re: question about PEAR vs. Zzoss installer

Stefan Neufeind wrote:

I'm +1 for adding such an optional parameter, if this doesn't lead to (technical) problems - e.g. when detecting if a package is installed or not etc. This should only affect the download stage of installation - once a package is installed, it is registered using the package.xml. There is a new problem that would be introduced, that of namespace. In other words, someone might release a package called "Config" or "XML_Util" that has nothing to do with PEAR. In this case, the installer would get confused about version numbering, not realizing that it's a different package entirely. I don't have a quick and automatic solution to this problem, it would require a larger discussion of how PEAR could interface with other non-PEAR pearwebs successfully like Horde, if there is a package name conflict. It might be as simple as adding another optional field to the <release> tag named <server> that specifies where updates should be grabbed from. Then the pear upgrade command could check the existing registry to see if it should override the default server with the value from this tag when requesting version info.

About the rules if or if not a pear-package might link to a non-pear- package: Maybe it would be good to generally disallow this for all packages in pear for the moment being - since I can't see why it should be needed. If discussions about an external dependeny being "absolutely necessary" we can still discuss if the other package might also be added/converted to pear, if there is a matching package in pear already (which should be a far better choice than an external dep) or if "in that special case" we allow an external dep. But generally I'm against allowing external deps in the first place. I agree that packages should not have dependencies outside of PEAR. The issue comes when you have applications. HTML_SetupWizard, for example, depends on several packages, and can be used as a standalone application with some programmatic configuration. phpDocumentor has several converters, with the possibility of adding others. I don't think it's a good idea to clutter the pear package space with new packages just for phpDocumentor converters, when they can be hosted off of phpdoc.org. It would basically be a first step towards implementing sub-packages - packages that cannot work without the application they were designed for, but are modular components that have a different stability level from the core of an application, and so should be released separately as well as in a bundle. I hope this makes sense, that was an awfully long sentence :).

Greg