Patch to re-order installation for dependencies

Hi, Those who have tried upgrade-all when you have many, many packages installed have noticed that it tends to die because the order of installation is important. The same is true of passing many package names on the command-line: the order is important. This patch seeks to take the first step towards solving that problem by grabbing dependency information from remote files (it is assumed that if the file is local, you can look up the dependency yourself, but there is no reason that can't be implemented as well). In addition, in many cases, you sit for a while downloading an application, only to find out that it depends on another one. I've patched in a call to remote-info that checks out dependencies, and fails prior to download if they aren't met. There is a design problem with the PEAR_Installer::install() method - it also downloads the packages, which means that to do any manipulation of installation order, it must be done in the PEAR_Command_Install::doInstall() method. I don't like the way it feels to hack in a patch there, so I wonder how hard it would be to move the downloading out of the install() method, and into a new download() method. This way, all of the packages could be downloaded and then ordered for installation. I think BC could be maintained by simply changing the doInstall() command to point to downloadAndInstall(), a wrapper that would call download and pass the downloaded file location to install(), which would operate unaware of any changes. There are potential issues, as I discovered today when pear.php.net was down. The XML_RPC class really doesn't like it when it can't connect, and will hang for a full two minutes before giving any error output. This means that without the code I added later, doing a "pear install package.xml" just hung the computer. Now, it does the same check that the installer does for downloadable packages, and as a hack, does a check to see if a package is a local package.xml by checking for package.xml in the name of the file. This is a big issue, and can be resolved by separating the download code from the install code, as then only local files need be passed to the install() command, and dependency checking of downloaded files can happen only in the download code. Another issue is I couldn't figure out is how to determine which version will be downloaded by an upgrade/install command, or whether I need to worry about it, because the remote-info just returns information about every release. In any case, try out the patch, with packages like SOAP that depend on HTTP_Request, which depends on other packages, etc. etc. Greg