Re: question about PEAR vs. Zzoss installer

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. Forwarding this discussion to the techis. E.g. Pierre - what do you think might be a good solution from a technical view looking at the installer you are currently working on? > 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. Some sort of "namespace" seems the only real solution. This would introduce some work but might be a good basis for futher extensions. > >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 :). We were talking about dependencies, right? So there should be nothing external that packages depend on. Greg, from your experience, is this 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 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 solve this interactively - like having a list "the following are recommended - what do you want to download additionally". Maybe then we might have need for a short (!) explaination (one sentence) for each additional package so people know what their options are basically. 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. Stefan