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

Request #11353 upgrade-all and upgrade commands to upgrade within the same stability level
Submitted: 2007-06-18 14:52 UTC
From: yunosh Assigned: dufuz
Status: Closed Package: PEAR (version 1.6.0)
PHP Version: Irrelevant OS:
Roadmaps: 1.8.0alpha1    

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:
Solve the problem : 32 + 16 = ?

 [2007-06-18 14:52 UTC] yunosh (Jan Schneider)
Description: ------------ pear list-upgrades already shows all newer version available within a package's stability level, even if the preferred state is higher, e.g.: Available Upgrades (stable): ========================================= Channel Package Local Remote Size Image_Text 0.5.2beta2 (beta) 0.6.0beta (beta) 60kB Mail_Mime 1.4.0 (stable) 1.5.0 (stable) 22kB MDB2_Schema 0.7.1 (beta) 0.7.2 (beta) 61kB pear upgrade-all should work the same way, so that a package is upgraded if a newer version with the same state than the one installed exists. I have already chosen to install a "weaker" package than my preferred state, so it's safe to assume that upgrades within this state are fine too. The only exception probably is, if a version of a more stable state exists "inbetween". E.g. if I have package 1.0.0beta1 (beta) installed and newer package versions 1.0.0 (stable) and 1.0.1beta1 (beta) exists. In this case I probably rather want to upgrade to 1.0.0 than 1.0.1beta1, though this is debatable and a warning might be sufficient.


 [2007-06-19 22:11 UTC] tias (Tias Guns)
Hey Jan, 'pear upgrade-all' shares the new and improved logic of 'pear list-upgrades'. It actually just calls pear upgrade <all packages>, which filters the packages with the logic of 'pear list-upgrades'. So the unnatural behaviour is in 'pear upgrade'. To go with the example of 'Image_Text': `pear upgrade Image_Text` currently gives: Failed to download pear/Image_Text within preferred state "stable", latest release is version 0.6.0beta, stability "beta", use "channel://" to install Cannot initialize 'channel://', invalid or missing package file Package "channel://" is not valid upgrade failed I totally agree on your statement about packages that are installed: > so it's safe to assume that upgrades within this state are fine too. So more natural behaviour would be: upgrade ok: channel:// 'pear upgrade' and 'pear install' are the same function and for 'pear install' this ''state protection'' is necessary, but I agree it isn't necessary for an upgrade. 'pear upgrade' actually thinks it can upgrade, as it gives (when doing upgrade-all): Will upgrade channel:// The code that doesn't allow the upgrade is in Downloader/Package.php::_analyzeDownloadURL() A real solution would be to adapt the behaviour of the downloader and make it more flexible. A shallow solution would be to make 'pear upgrade-all' run 'pear upgrade pkg-latest' OK, it seems ridiciously simple to implement the last behaviour, by adding it to the uptodate filter (see patch attached). I'm keeping the technical details in this comment for other developers.
 [2007-06-19 22:32 UTC] tias (Tias Guns)
Note, it breaks a test: tests/PEAR_Command_Install/upgrade-all/test.phpt Unfortunately I don't understand the xmlrpc things.
 [2007-06-19 22:55 UTC] cellog (Greg Beaver)
too late for 1.6.1 except for bugfixes, this can go in 1.7.0
 [2009-02-02 18:45 UTC] dufuz (Helgi Þormar Þorbjörnsson)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on by the end of next Sunday (CET). If this was a problem with the website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. This one was pretty nasty to track down for some reason - Tias did good job at pointing me in the right direction.