Description: ------------ # pear -V PEAR Version: 1.4.0a12 (CVS hacked as per bug 4278) PHP Version: 4.3.11 Zend Engine Version: 1.3.0 Running on: Linux ancilla.toggg.net 2.6.11-1.14_FC3smp #1 SMP Thu Apr 7 19:38:19 EDT 2005 i686 I did pear download-all and then: # pear install *.tgz on an empty machine The dependencies are not working : several package are installed but they should not ! Uninstalling them, and try to install them one by one, from net or from tgz proves it as then the install fails ! btw, the message is inversed as: # pear uninstall Auth_RADIUS pear/auth can be optionally used by installed package "pear/Auth_RADIUS" uninstall ok: channel://pear.php.net/Auth_RADIUS-1.0.4 Reproduce code: --------------- # pear uninstall HTML_Select_Common uninstall ok: channel://pear.php.net/HTML_Select_Common-1.1 # pear install HTML_Select_Common Did not download dependencies: pear/I18N, use --alldeps or --onlyreqdeps to download automatically pear/HTML_Select_Common requires package "pear/I18N" (version >= 0.8) Cannot install, dependencies failed install failed # pear install HTML_Select_Common-1.1.tgz Did not download dependencies: pear/I18N, use --alldeps or --onlyreqdeps to download automatically pear/HTML_Select_Common requires package "pear/I18N" (version >= 0.8) Cannot install, dependencies failed install failed # mv /usr/lib/php4/radius.so /usr/lib/php4/savradius.so [root@ancilla pecl]# pear uninstall Auth_RADIUS pear/auth can be optionally used by installed package "pear/Auth_RADIUS" uninstall ok: channel://pear.php.net/Auth_RADIUS-1.0.4 # pear install Auth_RADIUS downloading Auth_RADIUS-1.0.4.tgz ... Starting to download Auth_RADIUS-1.0.4.tgz (8,232 bytes) .....done: 8,232 bytes install ok: channel://pear.php.net/Auth_RADIUS-1.0.4 # pear uninstall Net_FTP pear/pear (recommended version 1.3.0) can be optionally used by installed package "pear/Net_FTP" uninstall ok: channel://pear.php.net/Net_FTP-1.3.1 # pear install Net_FTP pear/pear dependency package "pear/Net_FTP" downloaded version 1.3.1 is not the recommended version 1.3.0, but may be compatible, use --force to install pear/Net_FTP cannot be installed, conflicts with installed packages Cannot install, dependencies failed install failed # pear install Net_FTP-1.3.1.tgz pear/pear dependency package "pear/Net_FTP" downloaded version 1.3.1 is not the recommended version 1.3.0, but may be compatible, use --force to install pear/Net_FTP cannot be installed, conflicts with installed packages Cannot install, dependencies failed install failed # pear uninstall PHPUnit2 uninstall ok: channel://pear.php.net/PHPUnit2-2.2.0 # pear install PHPUnit2 pear/PHPUnit2 requires PHP (version >= 5.0.2, version <= 6.0.0), installed version is 4.3.11 pear/PHPUnit2 can optionally use PHP extension "dom" pear/PHPUnit2 can optionally use PHP extension "xdebug" (version >= 2.0.0beta2) Cannot install, dependencies failed install failed # pear install PHPUnit2-2.2.0.tgz pear/PHPUnit2 requires PHP (version >= 5.0.2, version <= 6.0.0), installed version is 4.3.11 pear/PHPUnit2 can optionally use PHP extension "dom" pear/PHPUnit2 can optionally use PHP extension "xdebug" (version >= 2.0.0beta2) Cannot install, dependencies failed install failed # pear uninstall DB_Ado uninstall ok: channel://pear.php.net/DB_ado-1.3 # pear install DB_Ado pear/DB_ado requires PHP extension "com" Cannot install, dependencies failed install failed

please try current CVS

Hi, greg ! I did the whole again, forced a "virgin" pear 1.3.5 from FC3 rpm after renaming pear install dir ... then upgraded to 1.4.0a12 CVS. No changes outer Net_FTP which is now right installed by the whole install or as single install. I think you upgraded the pear deps for it perhaps. I notice an increased memory usage so far I can see... Also the messages are changed, seems to be, regarding available alpha or beta pckgs. Long extracts of the test are here: http://toggg.com/pear/allpear050512.txt Why should the deps not be checked when pear install *.tgz ?

hi Bertrand, I can't believe you actually tried pear install *.tgz :) In any case, it's a good thing you did. I think the reason that this bug is happening is because when dependency verification occurs, it uses the list of downloaded packages to determine whether a dependency is validated by a downloaded package. Here is a scenario: Package A and B are downloaded, A depends on B Package A's dependencies validate Package B's dependencies fail, and B is not installed. In this situation, package A will be installed, even though package B's dependencies failed, because pre-download validation is not duplicated in install. This is a real problem, because A should not be installed. I've committed a fix to CVS that causes the dependency validation look to break out and start over if any packages fail, just to be sure that all deps are properly validated. This should be quite fast because of reliance upon caching, but may be a bit confusing to the user. Could you try it out and see if it works?

Hi greg, I'm really sorry but did not change... Nevertheless, I got a feeling it was much more quicker (dunno if it's coming from my inner timing ... :) perhaps a cache effect ... I did not clear it. In fact Auth_Radius did not install, but I think it's another problem: # peardev install *.tgz File http://pear.php.net:80/rest/r/radius/allreleases.xml not valid (received: HTTP/1.1 404 Not Found ) see http://toggg.com/pear/allpear050513.txt Something is wrong here, greg : the dependences *are* detected by the installer as reported in the beginning of the operation: ... pear/Auth_RADIUS requires package "pear/radius" (version >= 1.2.4) ... pear/DB_ado requires PHP extension "com" ... pear/HTML_Select_Common requires package "pear/I18N" (version >= 0.8) ... pear/PHPUnit2 requires PHP (version >= 5.0.2, version <= 6.0.0), installed version is 4.3.11 ... So why would that be "forgoten" hereafter ? Sorry, I still ignore the script ... For the memory question, it's also only a feeling ... Actually, as more packages installed thru this test, I it is a good reason form the memory usage to increase. If I get a moment, I could redo a memory mapping when you need it. Bon courage :) !

Please try again with current CVS merci

never mind. It doesn't work. I STILL can't find a reasonably sized test case that doesn't work. This bug is unfixable until either you or I finds a test case that has fewer than 154 files to install in it.

Bonjour greg ! I really understand the difficulty, the test set is so big, it's difficut to isolate. Again, it's weird as the dependence seem to be loosed in middle phase of the install. Anyway, as I tried to prove, any kind of dep is concerned. What I could try, robotize the test a little more, then generate random subsets untill it finds a good one. Subset should include at least one of the concerned pckgs. What you mean ?

This bug has been fixed in CVS. In case this was a documentation problem, the fix will show up at the end of next Sunday (CET) on pear.php.net. In case this was a pear.php.net website problem, the change will show up on the website in short time. Thank you for the report, and for helping us make PEAR better. got it :) Several other problems were fixed in the process of fixing the main bug - dependencies on pecl packages were all failing - package equality comparisons were case-sensitive (dep on Pear != PEAR package) The main problem was a combination of the loop detectDependencies() in PEAR_Downloader::download() and the validation loop in PEAR_Downloader::analyzeDependencies(). The analyzeDependencies loop was particular horrible. For detectDependencies() loop, when an invalid package was found (dependencies not satisfied), the package was removed, but validation needed to start over in case any of the earlier packages dependended on the failing package. In analyzeDependencies(), *NO* packages were ever removed once invalidated, and so were actually installed (as you noticed) even though their dependencies failed.

Hallelujah! I confirm everything ok. Bravo ! bertrand