The following error is pretty self explanatory: PHP version >= 4.1.0 or >= 5.0.4 Failed Error: Gallery 2 requires PHP version 4.1.0 or newer or 5.0.4 or newer. You have PHP version 5.0.4-gentoo-r1 installed. Contact your webserver administrator to request an upgrade, available at the PHP website. Is there any good reason *why* we brand php like this? Why weren't all the php apps in portage tested to make sure this doesn't cause breakage? Reproducible: Always Steps to Reproduce: 1.install php5 2.install gallery2 3.attempt to run the gallery configuration Actual Results: See the details... Expected Results: Gallery shouldn't have complained about having an insufficient php installation.
(In reply to comment #0) > > Is there any good reason *why* we brand php like this? Why weren't all the php > apps in portage tested to make sure this doesn't cause breakage? The branding for versions w/ backported patches was specifically requested by upstream. Not really php's fault that gallery sucks.
(In reply to comment #1) > (In reply to comment #0) > > > > Is there any good reason *why* we brand php like this? Why weren't all the php > > apps in portage tested to make sure this doesn't cause breakage? > > The branding for versions w/ backported patches was specifically requested by > upstream. Not really php's fault that gallery sucks. Ok, that's fine if upstream requested it. However, wouldn't it have been good to make sure this didn't break any apps in portage first? The answer of course is yes! Quite a few of these php web applications that run interactive setup routines via the web interface check for minimum versions of the required backend software. Even if gallery "sucks" in this manner, it still needs to be fixed. Besides, I don't think gallery upstream is supposed to account for the fact that upstream wants us to brand php.
(In reply to comment #2) > Ok, that's fine if upstream requested it. However, wouldn't it have been good > to make sure this didn't break any apps in portage first? The answer of course > is yes! Tu put this into context, those patches fix a serious security vulnerability (Bug 102373) and were already pretty much overdue. Otherwise, do you even have a list of all php apps in portage? And will you volunteer to test all of them? ;p There are still test request bugs for php5 compatibility unanswered for over a year. Your suggestion is plain impossible to carry out, there are really not enough people to do the job in time reasonable for security bugs. Gallery has a broken php version test and needs to be fixed, but please apply common sense.
(In reply to comment #3) > (In reply to comment #2) > > Ok, that's fine if upstream requested it. However, wouldn't it have been good > > to make sure this didn't break any apps in portage first? The answer of course > > is yes! > > Tu put this into context, those patches fix a serious security vulnerability > (Bug 102373) and were already pretty much overdue. I have no problem with that. Fixing security problems is a GoodThing(TM). > Otherwise, do you even have a > list of all php apps in portage? And will you volunteer to test all of them? > ;p No, but surely the php team does and will. I'm an arch maintainer, not an ebuild maintainer. > There are still test request bugs for php5 compatibility unanswered for over a > year. Your suggestion is plain impossible to carry out, there are really not > enough people to do the job in time reasonable for security bugs. The issue here really isn't security bugs. As I mentioned before, you would think that somebody might have thought to check if altering the version string that php returns breaks any packages that directly depend on php. These sorts of things are the job of the ebuild maintainers/herds, not arch teams. If everything was left to the arch teams, then many things would slip through the cracks, because in general, we don't test/keyword stuff for which there is no demand. In other cases, we are forced to push keywords through quickly because of broken deps. In the case of gallery here, I was trying to run it on sparc. Gallery has had sparc keywords for a long time I understand. Now, let's take a look at the dev-lang/php changelog entry by weeve: 09 Sep 2005; Jason Wever <weeve@gentoo.org> php-4.4.0.ebuild, php-5.0.4.ebuild: Added ~sparc keyword to help fix the broken dependencies of dev-php/PEAR-Date-1.4.3-r1. This is another case where unleashing broken deps on the tree causes all sorts of problems. The sparc arch scrambled to add keywords to fix the broken deps, and surely didn't have time to test it against everything in the tree. BTW, I'm not letting the web-apps herd off the hook either. They should have tested all of their stuff with the new php builds and coordinated with the php herd before everything was unmasked in the first place. > Gallery has a broken php version test and needs to be fixed, but please apply > common sense. Everything I just said is common sense. Anyway, these bugs aren't supposed to be a discussion forum, so I'll stop now.
(In reply to comment #4) > The issue here really isn't security bugs. As I mentioned before, you would > think that somebody might have thought to check if altering the version string > that php returns breaks any packages that directly depend on php. These sorts > of things are the job of the ebuild maintainers/herds, not arch teams. If > everything was left to the arch teams, then many things would slip through the > cracks, because in general, we don't test/keyword stuff for which there is no > demand. In other cases, we are forced to push keywords through quickly because > of broken deps. Uhm, I'm not sure if you really understand this issue - this has nothing in common with the unmasking/keywording the new stuff, we are talking about backported security fixes here, for which upstream requested this branding (see Bug 102373, comment #13) - the branding affects the old dev-php/{mod_}php stuff, likewise the new ones. And no - probably noone checked this, b/c it's not feasible in reasonable time. Fixing a serious security flaw is really more important then breaking a particular webapp, which implements a broken version check and is not even marked stable.
I'll only say this one more time, because you are misinterpreting and twisting what I am saying (no surprise there...). This bug report has *nothing* to do with security fixes, and *everything* to do with the fact that the new gentooified version string breaks gallery, and that nobody bothered to test for these sorts of breakages before the new php was unmasked. Please stop misinterpreting me. Thanks.
(In reply to comment #6) > This bug report has *nothing* to do > with security fixes, and *everything* to do with the fact that the new > gentooified version string breaks gallery, and that nobody bothered to test for > these sorts of breakages before the new php was unmasked. Please stop > misinterpreting me. Thanks. Eh??? How does this have nothing in common w/ security fixes? The branding if for the versions w/ security fixes *only*. Have you ever looked at the security bug which I have linked above? Again, this has zero in common with the unmasking stuff. Now, if you mean the version check in step 2 of the installer, then I'm not able to reproduce the problem. # php -v PHP 4.4.0-gentoo-r1 (cli) (built: Sep 17 2005 20:13:29) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies The version check passes OK.
(In reply to comment #7) > Now, if you mean the version check in step 2 of the installer, then I'm not able > to reproduce the problem. > > # php -v > PHP 4.4.0-gentoo-r1 (cli) (built: Sep 17 2005 20:13:29) > Copyright (c) 1997-2004 The PHP Group > Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies > > The version check passes OK. > Try with 5.0.4: ultra2 gallery # php -v PHP 5.0.4-gentoo-r1 (cli) (built: Sep 20 2005 22:34:42) Copyright (c) 1997-2004 The PHP Group Zend Engine v2.0.4-dev, Copyright (c) 1998-2004 Zend Technologies Note the error message I originally pasted into this bug: Error: Gallery 2 requires PHP version 4.1.0 or newer or 5.0.4 or newer. You have PHP version 5.0.4-gentoo-r1 installed. Contact your webserver administrator to request an upgrade, available at the PHP website. I suspect that it interprets 4.4.0-gentoo-r1 as being >= 4.1.0, but it doesn't recognize that 5.0.4-gentoo-r1 >= 5.0.4
(In reply to comment #8) > I suspect that it interprets 4.4.0-gentoo-r1 as being >= 4.1.0, but it doesn't > recognize that 5.0.4-gentoo-r1 >= 5.0.4 OK, there's nothing wrong w/ branding itself, but with the way it's done now: <?php // returns 1 $a = version_compare("5.0.4-gentoo-r1", "5.0.4", "<"); echo 'return code = '. $a; echo '<br>'; // returns -1 $b = version_compare("5.0.4-pl1-gentoo-r1", "5.0.4", "<"); echo 'return code = '. $b; ?> http://www.php.net/version_compare <snip> If a part contains special version strings these are handled in the following order: dev < alpha = a < beta = b < RC < pl. </snip> Re-assigning the bug.
Fixed in CVS, closing.
