Description: ------------ When doing upgrade-all, only the packages with state 'preferred state' are updated. So alpha version software can only be manually upgraded. This bug is fixed in the patch of bug #10372 Please note that when doing upgrade-all now, a package will always remain in its current state, unless upgraded manually. ~possibly~ previous pear behavior would upgrade it to 'preferred state' when possible (and not upgrade it otherwise). If a package should always be upgraded to its latest version (even when it is a different state) when doing upgrade-all, then the 'doInstall' should be prepended with $pref_state = $this->config->get('preferred_state'); $this->config->set('preferred_state', 'snapshot'); and appended with $this->config->set('preferred_state', $pref_state); If this behaviour should also be that way for 'pear upgrade <pkg>' then that code should be prepended and appended to $downloaded = &$this->downloader->download($packages); in doInstall(). Note that I've lost the importance of 'preferred_state' in this latter hack. Feel free to mail me to talk about this behaviour, or we could start talking about it on pear-dev@php too. Test script: --------------- ./pear install php_archive-0.9.2 # this is a alpha version package Expected result: ---------------- ./pear upgrade-all Will upgrade channel://pear.php.net/php_archive downloading PHP_Archive-0.10.0.tgz ... Starting to download PHP_Archive-0.10.0.tgz (68,853 bytes) .................done: 68,853 bytes upgrade ok: channel://pear.php.net/PHP_Archive-0.10. Actual result: -------------- ./pear upgrade-all (no response, no action)

I've just checked, currently pear will never upgrade a package to a 'higher' state, or say that this is possible: ./pear install XML_Parser-beta <blabla> install ok. ./pear upgrade-all <nothing!> ./pear upgrade XML_Parser pear/XML_Parser is already installed and is newer than detected release version 1.2.8 Cannot initialize 'XML_Parser', invalid or missing package file Package "XML_Parser" is not valid upgrade failed (equals: already to its latest version) This makes this bug worse then I thougt: non preferred-state packages are never upgraded ! (not even to the preferred state)

pear install XML_Parser-beta installs the latest version that is beta or stable, in this case 1.2.8. Your demonstration for XML_Parser is not good :). I confirmed the bug with the PHP_Archive. The bug only manifests itself when your preferred_state is not stable.

I seem to have a wrong view on the concept 'state'. Running 'install XML_Parser-beta' install 1.2.8 (=stable), while the latest beta release is 1.2.0beta3. Is this a bug too ? The original bug still remains the same, although it also happens for me, with a preferred-state of stable! g,T

the preferred_state of "beta" just means you prefer that the latest release that is either stable or beta should be installed. Not that you never want to install stable packages

sorry, I was wrong to mark this as verified. In my mind, PHP_Archive 0.10.0 was beta, and so pear config-set preferred_state beta should have caused pear upgrade-all to work. However, PHP_Archive 0.10.0 is *alpha* Your patch actually has a significant bug in it where preferred_state is ignored when retrieving the list of upgrades. This can cause people who wish to only upgrade to stable versions to suddenly upgrade to alpha releases - a VERY bad situation. So although it "fixes" this bug, it breaks one of the most important features of the PEAR Installer - the ability to filter out unstable releases

OK true, stable packages shouldn't be upgraded to beta packages if the preferred-state is stable, the concept 'state' was not clear to me at that time. Let's synchronize on how we want `upgrade` to work: 1) A higher version within the same state should be upgraded 2) A higher version in a higher state should be upgraded 3) A higher version in a lower state should be upgraded, IF that lower state is [the preferred state OR higher then the preferred state] Regardless of the current PEAR behaviour, do you agree on this ?

I agree with the first two statements of how upgrade should work. As I read it, the 3rd state is impossible (can't be both lower and higher than preferred_state at the same time)

I'll give examples to make it more clear, the preferred state is only relevant in the last statement !: 1) A higher version within the same state should be upgraded ex A: pref = stable; inst = 2.1 stable remote = 2.2 stable -> upgrade ex B: pref = stable; inst = 1.1 beta remote = 1.2 beta -> upgrade 2) A higher version in a higher state should be upgraded ex A: pref = stable; inst = 1.1 beta remote = 2.1 stable -> upgrade ex B: pref = stable; inst = 0.1 alpha remote = 1.1 beta -> upgrade 3) A higher version in a lower state should be upgraded, IF that lower state is [the preferred state OR higher then the preferred state] ex A1: pref = stable; inst = 2.1 stable remote = 3.0 beta (= higher version, lower state) -> NO upgrade (state[beta] < pref. state[stable]) ex A2: pref = beta; inst = 2.1 stable remote = 3.0 beta -> upgrade (state[beta] == pref. state[beta]) ex A3: pref = alpha; inst = 2.1 stable remote = 3.0 beta -> upgrade (state[beta] > pref. state[alpha]) I think it is important to make the installer work in this logical way, to give an example: set your preferred_state to stable pear install PEAR_Frontend_Web-0.5.1 pear upgrade PEAR_Frontend_Web (latest is 0.5.2) -> Nothing !! That is very unfortunate behaviour, as pear uninstall PEAR_Frontend_Web pear install PEAR_Frontend_Web-alpha would install the latest version (0.5.2) So the default user will only get updates of packages that are already stable, very unfortunate imho.

ok, this makes more sense, changing summary to be clearer

Attached is a patch that implements the behaviour described above. I've added comments to make sure that everybody understands it right. g,T

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net 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.

seems not to work: # pear version PEAR Version: 1.7.2 PHP Version: 5.2.0-8+etch11 Zend Engine Version: 2.2.0 # pear upgrade-all Will upgrade channel://pear.php.net/php_beautifier Failed to download pear/php_beautifier within preferred state "stable", latest release is version 0.1.14, stability "beta", use "channel://pear.php.net/php_beautifier-0.1.14" to install Cannot initialize 'channel://pear.php.net/php_beautifier', invalid or missing package file Package "channel://pear.php.net/php_beautifier" is not valid upgrade-all failed

this was only implemented for upgrade, not upgrade-all command

oh, i had think this would be the same code (just called more often) ... ;-) will it be implemented for upgrade-all too? and id didn't see it mentioned, so i just note it here for completeness: 4) the highest equal or above preferred state should be upgraded ex A: pref = stable; inst = 2.0 stable remote = 2.0.1 stable remote = 2.1 beta -> upgrade to 2.0.1 stable ex B: pref = stable; inst = 2.0 beta remote = 2.0 stable remote = 2.1 beta -> upgrade to 2.0 stable

IMHO upgrade and upgrade-all should work the same in this regard.

And "upgrade" doesn't work as expected either, if you are using the state suffix for package names, instead of the preferred_state setting. Example: preferred_state set to stable, I'd expect pear upgrade MDB2_Driver_mysql-beta to upgrade from MDB2_Driver_mysql 1.4.1 (stable) to MDB2_Driver_mysql 1.5.0b1 (beta). But it only works if set preferred_state to beta (and then I don't need the suffix anymore, of course).

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net 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 was fixed as a part of request #11353