Re: question about PEAR vs. Zzoss installer

Stefan Neufeind wrote:

On 16 Aug 2003 at 15:14, Greg Beaver wrote:

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.

Well in Java afaik they handle namespaces by including domainnames to indicate the namespace. If I remember correctly class com.sun.java.Class1 or something (read from left to right). This does not necessarily be the url under which the package can be found but this is just a solution to ensure that it's unique. Maybe we could implement a similar namespace for "pear.php.net"? Having just PEAR::Package would also be okay - but what if more people use it and e.g. many people are named "Mueller" or similar as surname. Then Mueller::Package wouldn't be unique any longer. The only drawback to this is that a registry of namespace => package prefix would be required, which I think is not likely to happen unless pear-group likes the idea, and someone jumps forward to maintain it.

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 :).

We were talking about dependencies, right? So there should be nothing external that packages depend on. Greg, from your experience, is this Imagine this situation: someone wants to write an application based on a few PEAR packages and a few Horde packages that work together, and distribute it within a company. Currently, they cannot use the PEAR installer. Again, I'm not talking about packages, I'm talking about standalone applications that use packages, a very different situation.

I know PEAR wishes to keep PEAR pure, but the real world of open source is that you mix and match the best of anything and everything to make things work. phpDocumentor uses a PDF generation package that is based on sourceforge, PEAR's HTML_TreeMenu, Smarty, and so on. It's silly for us to bundle all of these applications when they may already be installed. This, I imagine, is why PEAR was started in the first place? Opening up this aspect of applications (NOT packages - let's be clear here), will help to turn around the common view of PEAR as a closed society, and help people realize it's actually usable for almost any situation. <can contents="worms" action="open">In other words, I think the greatest strength of PEAR is its ability to handle dependencies, and to allow them. Greater dependency = leaner install, easier maintenance (if there's a bug, you know how to fix it for every application - pear upgrade packagename), and so on. For applications, the ability to support dependencies is essential, and I would suggest that the ability to install and configure packages both within and outside of PEAR might be the quickest way to ensure universal usage of PEAR by PHP users.</can> I'm not suggesting a big change here like some of my other posts, but I did want to explain my motivations.

possible with all packages? You wrote about "additional features" that require certain packages. So should we also include a way for "recommended" and maybe "related" packages? Like installing a graphic the optional attribute of <dep> already handles this problem nicely.

library or something suggests you install support-libs for jpeg, gif, tif etc. but doesn't demand that? But how would we deal with this in case of automatic package installations / upgrades? You can at least optional dependencies should never be automatically installed, but should be automatically upgraded if they are already installed.

This seems a good thought to me. And although it might introduce a lot of discussion and work combined I believe it's worth the effort. Agreed