Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.10.15

Bug #13425 Dep package install fails when 2 vers of dep exist, even when depchain is OK
Submitted: 2008-03-18 10:11 UTC
From: timj Assigned:
Status: Wont fix Package: PEAR (version 1.7.1)
PHP Version: Irrelevant OS:
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 48 - 11 = ?

 
 [2008-03-18 10:11 UTC] timj (Tim Jackson)
Description: ------------ This is related to bug #11641 If I have the following packages: package X requires "Foo_Bar", no recommended version requires Y package Y requires "Foo_Bar", recommended version 1.0.0 and Foo_Bar exists as both v1.0.0 and 1.0.1 on the channel server, then an attempt to install X via "pear install --onlyreqdeps" results in a failure with the error: Duplicate package channel://whatever/Foo_Bar-1.0.1 found Duplicate package channel://whatever/Foo_Bar-1.0.0 found even though installing *either* 1.0.0 or 1.0.1 would fully satisfy the deps in either case. A warning is probably justified but installing neither package is not a good resolution. This is closely related to (but not the same as) bug #11195.

Comments

 [2008-03-19 15:08 UTC] timj (Tim Jackson)
At a really quick glance, PEAR_Downloader_Package has a function "detectStupidDuplicates", the comment for which states: * Detect duplicate package names with differing versions * * If a user requests to install Date 1.4.6 and Date 1.4.7, * for instance, this is a logic error. This method * detects this situation. If this is indeed where the error originates, the problem is that "requesting" to install Date 1.4.6 and 1.4.7 is *not* "stupid" and *not* an error if it happens automatically as a result of dependency resolution. However I could be barking up completely the wrong tree, this was a 2 minute glance at the code.
 [2008-03-29 13:12 UTC] dufuz (Helgi Þormar Þorbjörnsson)
I might be misunderstanding something but you can't have 2 versions or more of the same package in PEAR installed at the same time, thus picking the higher dep (I believe) tho looking at your comments it seems it decides to install nothing rather than the highest / most satisfying dep which kinda strikes me as weird. The only other way around it would be to install one of the deps as Date-1.4.6 and the other one in the Date dir, which is something no PHP script will expect.
 [2008-03-29 13:23 UTC] dufuz (Helgi Þormar Þorbjörnsson)
I went in and made the detectStupidDuplicates function a bit more readable and having looked at it, this function merely finds the duplications and puts them in an array, then Downloader.php checks if the error params array is set, if so loop it and then return (basically just stops the whole thing) One possible solution would be to go to line 392 of Downloader.php and do some magic ... add resolveStupidDependency() which would pick the proper dep somehow and then pass it to the failing part if that does not work, else do the same thing but merely as a warning
 [2008-04-09 22:20 UTC] timj (Tim Jackson)
Yes, this bug is not about installing two versions of the same package (we don't support that), but the fact that installing *nothing* when there are two perfectly good candidate versions is silly. Your idea about having a function to resolve the situation (simply picking the newest of the candidates will do, though comparing the versions could be interesting as a string/integer comparison is not good enough - is there an internal function to compare two versions correctly?) is fine - HOWEVER, there is a nasty but unrelated bug (bug #13427) which means that if we merely do this then PEAR will end up installing versions which had been explicitly excluded. This unfortunately shows a rather nasty hole at the heart of PEAR's dependency resolution.
 [2008-05-14 03:37 UTC] cellog (Greg Beaver)
Unfortunately, this would require a complete rewrite of the dependency handling mechanism of PEAR. In other words, only Pyrus is truly capable of resolving cases like this one, as Pyrus considers all packages at the same time when calculating dependency issues. PEAR handles each package one at a time, and so is incapable of fully handling this situation. I'm open for patches, but I need to devote full time to Pyrus moving forward.