Re: second post on dependencies in PEAR 1.4.0

Martin Jansen wrote:

On Thu Feb 17, 2005 at 01:2908AM -0500, Greg Beaver wrote:

For those of you who use dependencies, it would be good to find out the whole scoop on how they will work in PEAR 1.4.0. You can read all about it at: http://greg.chiaraquartet.net/archives/21-Dependencies-in-PEAR-1.4.0,-Part-2.html

This isn't related to Part 2, but more to Part 1: I do not really understand what the PEAR installer dependency does. Can you give a short example? A perfect example:

PDO requires the PEAR Installer version 1.3.5, but does not need any of the PHP classes. As Wez put it "the users would get really confused if I put a dependency on PEAR" For PHP packages, imagine this scenario: PEAR 1.4.3 fixes a bug in a feature of package.xml 2.0 that would prevent a package from being installed correctly. Package Foo can require PEAR Installer version 1.4.3. This dependency also does not require PEAR to actually be installed - it does not access the registry, it instead compares the version to a replacement (one of those @version@ thingos), which also allows installing packages to restore a corrupted registry.

And it would be interesting to see if the installer supports something like dependency groups similar to Debian's dpkg system: There one can set dependencies like "This package depends on Package 1 or Package 2 or Package 3 or ... or Package n". Do we support this, too? Well, I considered implementing this using an <or> tag, but decided that a better tack in this situation would be to put the or logic in a userspace class (this is harder to do with C, since compilation requires all valid libraries prior to being able to build it), and the choices as either optional dependencies or in a dependency group.

However, this doesn't allowed required dependencies to have an either/or choice. Honestly, I think that it is not necessary in PHP to say "I can use Package 1 or Package 2, but not at the same time." Why? If Package 1 actually conflicts with Package 2, the installer won't allow them to be both installed at the same time anyways (assuming they follow the PEAR file/directory naming schemes). Better is to note an optional dependency on either one, and to do a run-time check for the presence and fail if neither is found. Naturally, I am open to changes for the second alpha release of 1.4.0 Greg